{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-image-6.8.0-100-generic", "linux-modules-6.8.0-100-generic" ], "removed": [ "linux-image-6.8.0-90-generic", "linux-modules-6.8.0-90-generic" ], "diff": [ "base-files", "cloud-init", "gcc-14-base", "gir1.2-glib-2.0", "libc-bin", "libc6", "libdrm-common", "libdrm2", "libexpat1", "libgcc-s1", "libglib2.0-0t64", "libgnutls30t64", "libldap2", "libpng16-16t64", "libpython3.12-minimal", "libpython3.12-stdlib", "libstdc++6", "linux-image-virtual", "python-apt-common", "python3-apt", "python3-distupgrade", "python3.12", "python3.12-minimal", "ubuntu-release-upgrader-core" ] } }, "diff": { "deb": [ { "name": "base-files", "from_version": { "source_package_name": "base-files", "source_package_version": "13ubuntu10.3", "version": "13ubuntu10.3" }, "to_version": { "source_package_name": "base-files", "source_package_version": "13ubuntu10.4", "version": "13ubuntu10.4" }, "cves": [], "launchpad_bugs_fixed": [ 2140756 ], "changes": [ { "cves": [], "log": [ "", " * /etc/issue{,.net}, /etc/{lsb,os}-release: bump version to 24.04.4", " (LP: #2140756)", "" ], "package": "base-files", "version": "13ubuntu10.4", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2140756 ], "author": "Florent 'Skia' Jacquet ", "date": "Fri, 06 Feb 2026 08:23:01 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "cloud-init", "from_version": { "source_package_name": "cloud-init", "source_package_version": "25.2-0ubuntu1~24.04.1", "version": "25.2-0ubuntu1~24.04.1" }, "to_version": { "source_package_name": "cloud-init", "source_package_version": "25.3-0ubuntu1~24.04.1", "version": "25.3-0ubuntu1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2131604 ], "changes": [ { "cves": [], "log": [ "", " * d/p/retain-setuptools.patch: avoid upstream switch to meson build backend.", " * refresh patches:", " - d/p/no-nocloud-network.patch", " - d/p/no-single-process.patch", " - d/p/grub-dpkg-support.patch", " * Upstream snapshot based on 25.3. (LP: #2131604).", " List of changes from upstream can be found at", " https://raw.githubusercontent.com/canonical/cloud-init/25.3/ChangeLog", "" ], "package": "cloud-init", "version": "25.3-0ubuntu1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2131604 ], "author": "Chad Smith ", "date": "Sat, 15 Nov 2025 11:02:56 -0700" } ], "notes": null, "is_version_downgrade": false }, { "name": "gcc-14-base", "from_version": { "source_package_name": "gcc-14", "source_package_version": "14.2.0-4ubuntu2~24.04", "version": "14.2.0-4ubuntu2~24.04" }, "to_version": { "source_package_name": "gcc-14", "source_package_version": "14.2.0-4ubuntu2~24.04.1", "version": "14.2.0-4ubuntu2~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2101084 ], "changes": [ { "cves": [], "log": [ "", " * d/p/pr118976.diff: Fix memory corruption when executing 256-bit", " Scalable Vector Extensions code on 128-bit CPUs (LP: #2101084).", "" ], "package": "gcc-14", "version": "14.2.0-4ubuntu2~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2101084 ], "author": "Vladimir Petko ", "date": "Fri, 19 Dec 2025 10:36:50 +1300" } ], "notes": null, "is_version_downgrade": false }, { "name": "gir1.2-glib-2.0", "from_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.7", "version": "2.80.0-6ubuntu3.7" }, "to_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.8", "version": "2.80.0-6ubuntu3.8" }, "cves": [ { "cve": "CVE-2026-1484", "url": "https://ubuntu.com/security/CVE-2026-1484", "cve_description": "A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.", "cve_priority": "medium", "cve_public_date": "2026-01-27 14:15:00 UTC" }, { "cve": "CVE-2026-1485", "url": "https://ubuntu.com/security/CVE-2026-1485", "cve_description": "A flaw was found in Glib's content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.", "cve_priority": "medium", "cve_public_date": "2026-01-27 14:15:00 UTC" }, { "cve": "CVE-2026-1489", "url": "https://ubuntu.com/security/CVE-2026-1489", "cve_description": "A flaw was found in GLib. An integer overflow vulnerability in its Unicode case conversion implementation can lead to memory corruption. By processing specially crafted and extremely large Unicode strings, an attacker could trigger an undersized memory allocation, resulting in out-of-bounds writes. This could cause applications utilizing GLib for string conversion to crash or become unstable.", "cve_priority": "medium", "cve_public_date": "2026-01-27 15:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-1484", "url": "https://ubuntu.com/security/CVE-2026-1484", "cve_description": "A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.", "cve_priority": "medium", "cve_public_date": "2026-01-27 14:15:00 UTC" }, { "cve": "CVE-2026-1485", "url": "https://ubuntu.com/security/CVE-2026-1485", "cve_description": "A flaw was found in Glib's content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.", "cve_priority": "medium", "cve_public_date": "2026-01-27 14:15:00 UTC" }, { "cve": "CVE-2026-1489", "url": "https://ubuntu.com/security/CVE-2026-1489", "cve_description": "A flaw was found in GLib. An integer overflow vulnerability in its Unicode case conversion implementation can lead to memory corruption. By processing specially crafted and extremely large Unicode strings, an attacker could trigger an undersized memory allocation, resulting in out-of-bounds writes. This could cause applications utilizing GLib for string conversion to crash or become unstable.", "cve_priority": "medium", "cve_public_date": "2026-01-27 15:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: integer overflow in Base64 encoding", " - debian/patches/CVE-2026-1484-1.patch: use gsize to prevent potential", " overflow in glib/gbase64.c.", " - debian/patches/CVE-2026-1484-2.patch: ensure that the out value is", " within allocated size in glib/gbase64.c.", " - CVE-2026-1484", " * SECURITY UPDATE: buffer underflow via header length", " - debian/patches/CVE-2026-1485.patch: do not overflow if header is", " longer than MAXINT in gio/gcontenttype.c.", " - CVE-2026-1485", " * SECURITY UPDATE: integer overflow via Unicode case conversion", " - debian/patches/CVE-2026-1489-1.patch: use size_t for output_marks", " length in glib/guniprop.c.", " - debian/patches/CVE-2026-1489-2.patch: do not convert size_t to gint", " in glib/guniprop.c.", " - debian/patches/CVE-2026-1489-3.patch: ensure we do not overflow size", " in glib/guniprop.c.", " - debian/patches/CVE-2026-1489-4.patch: add test debug information when", " parsing input files in glib/tests/unicode.c.", " - CVE-2026-1489", "" ], "package": "glib2.0", "version": "2.80.0-6ubuntu3.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 28 Jan 2026 12:53:07 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libc-bin", "from_version": { "source_package_name": "glibc", "source_package_version": "2.39-0ubuntu8.6", "version": "2.39-0ubuntu8.6" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.39-0ubuntu8.7", "version": "2.39-0ubuntu8.7" }, "cves": [ { "cve": "CVE-2025-15281", "url": "https://ubuntu.com/security/CVE-2025-15281", "cve_description": "Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.", "cve_priority": "medium", "cve_public_date": "2026-01-20 14:16:00 UTC" }, { "cve": "CVE-2026-0861", "url": "https://ubuntu.com/security/CVE-2026-0861", "cve_description": "Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption. Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc. Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.", "cve_priority": "medium", "cve_public_date": "2026-01-14 21:15:00 UTC" }, { "cve": "CVE-2026-0915", "url": "https://ubuntu.com/security/CVE-2026-0915", "cve_description": "Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.", "cve_priority": "medium", "cve_public_date": "2026-01-15 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15281", "url": "https://ubuntu.com/security/CVE-2025-15281", "cve_description": "Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.", "cve_priority": "medium", "cve_public_date": "2026-01-20 14:16:00 UTC" }, { "cve": "CVE-2026-0861", "url": "https://ubuntu.com/security/CVE-2026-0861", "cve_description": "Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption. Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc. Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.", "cve_priority": "medium", "cve_public_date": "2026-01-14 21:15:00 UTC" }, { "cve": "CVE-2026-0915", "url": "https://ubuntu.com/security/CVE-2026-0915", "cve_description": "Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.", "cve_priority": "medium", "cve_public_date": "2026-01-15 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: use-after-free in wordexp_t fields", " - debian/patches/CVE-2025-15281.patch: posix: Reset wordexp_t fields", " with WRDE_REUSE", " - CVE-2025-15281", " * SECURITY UPDATE: integer overflow in memalign", " - debian/patches/CVE-2026-0861.patch: memalign: reinstate alignment", " overflow check", " - CVE-2026-0861", " * SECURITY UPDATE: memory leak in NSS DNS", " - debian/patches/CVE-2026-0915.patch: resolv: Fix NSS DNS backend for", " getnetbyaddr", " - CVE-2026-0915", "" ], "package": "glibc", "version": "2.39-0ubuntu8.7", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Nishit Majithia ", "date": "Fri, 30 Jan 2026 13:57:54 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libc6", "from_version": { "source_package_name": "glibc", "source_package_version": "2.39-0ubuntu8.6", "version": "2.39-0ubuntu8.6" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.39-0ubuntu8.7", "version": "2.39-0ubuntu8.7" }, "cves": [ { "cve": "CVE-2025-15281", "url": "https://ubuntu.com/security/CVE-2025-15281", "cve_description": "Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.", "cve_priority": "medium", "cve_public_date": "2026-01-20 14:16:00 UTC" }, { "cve": "CVE-2026-0861", "url": "https://ubuntu.com/security/CVE-2026-0861", "cve_description": "Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption. Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc. Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.", "cve_priority": "medium", "cve_public_date": "2026-01-14 21:15:00 UTC" }, { "cve": "CVE-2026-0915", "url": "https://ubuntu.com/security/CVE-2026-0915", "cve_description": "Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.", "cve_priority": "medium", "cve_public_date": "2026-01-15 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15281", "url": "https://ubuntu.com/security/CVE-2025-15281", "cve_description": "Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.", "cve_priority": "medium", "cve_public_date": "2026-01-20 14:16:00 UTC" }, { "cve": "CVE-2026-0861", "url": "https://ubuntu.com/security/CVE-2026-0861", "cve_description": "Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption. Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc. Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.", "cve_priority": "medium", "cve_public_date": "2026-01-14 21:15:00 UTC" }, { "cve": "CVE-2026-0915", "url": "https://ubuntu.com/security/CVE-2026-0915", "cve_description": "Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.", "cve_priority": "medium", "cve_public_date": "2026-01-15 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: use-after-free in wordexp_t fields", " - debian/patches/CVE-2025-15281.patch: posix: Reset wordexp_t fields", " with WRDE_REUSE", " - CVE-2025-15281", " * SECURITY UPDATE: integer overflow in memalign", " - debian/patches/CVE-2026-0861.patch: memalign: reinstate alignment", " overflow check", " - CVE-2026-0861", " * SECURITY UPDATE: memory leak in NSS DNS", " - debian/patches/CVE-2026-0915.patch: resolv: Fix NSS DNS backend for", " getnetbyaddr", " - CVE-2026-0915", "" ], "package": "glibc", "version": "2.39-0ubuntu8.7", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Nishit Majithia ", "date": "Fri, 30 Jan 2026 13:57:54 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libdrm-common", "from_version": { "source_package_name": "libdrm", "source_package_version": "2.4.122-1~ubuntu0.24.04.2", "version": "2.4.122-1~ubuntu0.24.04.2" }, "to_version": { "source_package_name": "libdrm", "source_package_version": "2.4.125-1ubuntu0.1~24.04.1", "version": "2.4.125-1ubuntu0.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2126037, 2127944, 2104352, 2100483 ], "changes": [ { "cves": [], "log": [ "", " * Backport to noble. (LP: #2126037)", " - amdgpu-add-env-support-for-amdgpu-ids.patch dropped as it has", " changed on the upstream merge request and hasn't landed yet", "" ], "package": "libdrm", "version": "2.4.125-1ubuntu0.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2126037 ], "author": "Timo Aaltonen ", "date": "Fri, 07 Nov 2025 14:50:51 +0200" }, { "cves": [], "log": [ "", " * patches: Identify APUs from hardware (LP: #2127944)", "" ], "package": "libdrm", "version": "2.4.125-1ubuntu0.1", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2127944 ], "author": "Timo Aaltonen ", "date": "Fri, 24 Oct 2025 17:43:46 +0300" }, { "cves": [], "log": [ "", " [ Jianfeng Liu ]", " * Enable build libdrm-intel1 for loong64. (Closes: #1107223)", "", " [ Timo Aaltonen ]", " * New upstream release.", " * patches: Drop the upstreamed fix for xf86drm.", " * symbols: Updated.", "" ], "package": "libdrm", "version": "2.4.125-1", "urgency": "medium", "distributions": "experimental", "launchpad_bugs_fixed": [], "author": "Timo Aaltonen ", "date": "Wed, 25 Jun 2025 10:46:34 +0300" }, { "cves": [], "log": [ "", " [ Daniel van Vugt ]", " * Add xf86drm-Handle-NULL-in-drmCopyVersion.patch (LP: #2104352)", "", " [ Bo YU ]", " * Enable building libdrm-intel1 for riscv64 (Closes: #1085314)", "" ], "package": "libdrm", "version": "2.4.124-2", "urgency": "medium", "distributions": "unstable", "launchpad_bugs_fixed": [ 2104352 ], "author": "Timo Aaltonen ", "date": "Tue, 01 Apr 2025 11:08:19 +0300" }, { "cves": [], "log": [ "", " * New upstream release.", " * amdgpu-add-env-support-for-amdgpu-ids.patch: Add a patch to allow", " using an env variable for amdgpu.ids path. (LP: #2100483)", "" ], "package": "libdrm", "version": "2.4.124-1", "urgency": "medium", "distributions": "unstable", "launchpad_bugs_fixed": [ 2100483 ], "author": "Timo Aaltonen ", "date": "Thu, 27 Feb 2025 14:57:25 +0200" }, { "cves": [], "log": [ "", " * New upstream release.", " * Add upstream metadata, drop old git url from d/watch.", " * Update signing-key.asc.", "" ], "package": "libdrm", "version": "2.4.123-1", "urgency": "medium", "distributions": "unstable", "launchpad_bugs_fixed": [], "author": "Timo Aaltonen ", "date": "Tue, 10 Sep 2024 11:03:50 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libdrm2", "from_version": { "source_package_name": "libdrm", "source_package_version": "2.4.122-1~ubuntu0.24.04.2", "version": "2.4.122-1~ubuntu0.24.04.2" }, "to_version": { "source_package_name": "libdrm", "source_package_version": "2.4.125-1ubuntu0.1~24.04.1", "version": "2.4.125-1ubuntu0.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2126037, 2127944, 2104352, 2100483 ], "changes": [ { "cves": [], "log": [ "", " * Backport to noble. (LP: #2126037)", " - amdgpu-add-env-support-for-amdgpu-ids.patch dropped as it has", " changed on the upstream merge request and hasn't landed yet", "" ], "package": "libdrm", "version": "2.4.125-1ubuntu0.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2126037 ], "author": "Timo Aaltonen ", "date": "Fri, 07 Nov 2025 14:50:51 +0200" }, { "cves": [], "log": [ "", " * patches: Identify APUs from hardware (LP: #2127944)", "" ], "package": "libdrm", "version": "2.4.125-1ubuntu0.1", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2127944 ], "author": "Timo Aaltonen ", "date": "Fri, 24 Oct 2025 17:43:46 +0300" }, { "cves": [], "log": [ "", " [ Jianfeng Liu ]", " * Enable build libdrm-intel1 for loong64. (Closes: #1107223)", "", " [ Timo Aaltonen ]", " * New upstream release.", " * patches: Drop the upstreamed fix for xf86drm.", " * symbols: Updated.", "" ], "package": "libdrm", "version": "2.4.125-1", "urgency": "medium", "distributions": "experimental", "launchpad_bugs_fixed": [], "author": "Timo Aaltonen ", "date": "Wed, 25 Jun 2025 10:46:34 +0300" }, { "cves": [], "log": [ "", " [ Daniel van Vugt ]", " * Add xf86drm-Handle-NULL-in-drmCopyVersion.patch (LP: #2104352)", "", " [ Bo YU ]", " * Enable building libdrm-intel1 for riscv64 (Closes: #1085314)", "" ], "package": "libdrm", "version": "2.4.124-2", "urgency": "medium", "distributions": "unstable", "launchpad_bugs_fixed": [ 2104352 ], "author": "Timo Aaltonen ", "date": "Tue, 01 Apr 2025 11:08:19 +0300" }, { "cves": [], "log": [ "", " * New upstream release.", " * amdgpu-add-env-support-for-amdgpu-ids.patch: Add a patch to allow", " using an env variable for amdgpu.ids path. (LP: #2100483)", "" ], "package": "libdrm", "version": "2.4.124-1", "urgency": "medium", "distributions": "unstable", "launchpad_bugs_fixed": [ 2100483 ], "author": "Timo Aaltonen ", "date": "Thu, 27 Feb 2025 14:57:25 +0200" }, { "cves": [], "log": [ "", " * New upstream release.", " * Add upstream metadata, drop old git url from d/watch.", " * Update signing-key.asc.", "" ], "package": "libdrm", "version": "2.4.123-1", "urgency": "medium", "distributions": "unstable", "launchpad_bugs_fixed": [], "author": "Timo Aaltonen ", "date": "Tue, 10 Sep 2024 11:03:50 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libexpat1", "from_version": { "source_package_name": "expat", "source_package_version": "2.6.1-2ubuntu0.3", "version": "2.6.1-2ubuntu0.3" }, "to_version": { "source_package_name": "expat", "source_package_version": "2.6.1-2ubuntu0.4", "version": "2.6.1-2ubuntu0.4" }, "cves": [ { "cve": "CVE-2026-24515", "url": "https://ubuntu.com/security/CVE-2026-24515", "cve_description": "In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.", "cve_priority": "medium", "cve_public_date": "2026-01-23 08:16:00 UTC" }, { "cve": "CVE-2026-25210", "url": "https://ubuntu.com/security/CVE-2026-25210", "cve_description": "In libexpat before 2.7.4, the doContent function does not properly determine the buffer size bufSize because there is no integer overflow check for tag buffer reallocation.", "cve_priority": "medium", "cve_public_date": "2026-01-30 07:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-24515", "url": "https://ubuntu.com/security/CVE-2026-24515", "cve_description": "In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.", "cve_priority": "medium", "cve_public_date": "2026-01-23 08:16:00 UTC" }, { "cve": "CVE-2026-25210", "url": "https://ubuntu.com/security/CVE-2026-25210", "cve_description": "In libexpat before 2.7.4, the doContent function does not properly determine the buffer size bufSize because there is no integer overflow check for tag buffer reallocation.", "cve_priority": "medium", "cve_public_date": "2026-01-30 07:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: NULL pointer dereference", " - debian/patches/CVE-2026-24515.patch: updates", " XML_ExternalEntityParserCreate to copy unknown encoding handler user", " data in expat/lib/xmlparse.c.", " - CVE-2026-24515", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-25210*.patch: adds an integer overflow check for", " tag buffer reallocation in the doContent function of", " expat/lib/xmlparse.c.", " - CVE-2026-25210", "" ], "package": "expat", "version": "2.6.1-2ubuntu0.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Ian Constantin ", "date": "Wed, 04 Feb 2026 17:24:08 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libgcc-s1", "from_version": { "source_package_name": "gcc-14", "source_package_version": "14.2.0-4ubuntu2~24.04", "version": "14.2.0-4ubuntu2~24.04" }, "to_version": { "source_package_name": "gcc-14", "source_package_version": "14.2.0-4ubuntu2~24.04.1", "version": "14.2.0-4ubuntu2~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2101084 ], "changes": [ { "cves": [], "log": [ "", " * d/p/pr118976.diff: Fix memory corruption when executing 256-bit", " Scalable Vector Extensions code on 128-bit CPUs (LP: #2101084).", "" ], "package": "gcc-14", "version": "14.2.0-4ubuntu2~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2101084 ], "author": "Vladimir Petko ", "date": "Fri, 19 Dec 2025 10:36:50 +1300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libglib2.0-0t64", "from_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.7", "version": "2.80.0-6ubuntu3.7" }, "to_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.8", "version": "2.80.0-6ubuntu3.8" }, "cves": [ { "cve": "CVE-2026-1484", "url": "https://ubuntu.com/security/CVE-2026-1484", "cve_description": "A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.", "cve_priority": "medium", "cve_public_date": "2026-01-27 14:15:00 UTC" }, { "cve": "CVE-2026-1485", "url": "https://ubuntu.com/security/CVE-2026-1485", "cve_description": "A flaw was found in Glib's content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.", "cve_priority": "medium", "cve_public_date": "2026-01-27 14:15:00 UTC" }, { "cve": "CVE-2026-1489", "url": "https://ubuntu.com/security/CVE-2026-1489", "cve_description": "A flaw was found in GLib. An integer overflow vulnerability in its Unicode case conversion implementation can lead to memory corruption. By processing specially crafted and extremely large Unicode strings, an attacker could trigger an undersized memory allocation, resulting in out-of-bounds writes. This could cause applications utilizing GLib for string conversion to crash or become unstable.", "cve_priority": "medium", "cve_public_date": "2026-01-27 15:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-1484", "url": "https://ubuntu.com/security/CVE-2026-1484", "cve_description": "A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.", "cve_priority": "medium", "cve_public_date": "2026-01-27 14:15:00 UTC" }, { "cve": "CVE-2026-1485", "url": "https://ubuntu.com/security/CVE-2026-1485", "cve_description": "A flaw was found in Glib's content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.", "cve_priority": "medium", "cve_public_date": "2026-01-27 14:15:00 UTC" }, { "cve": "CVE-2026-1489", "url": "https://ubuntu.com/security/CVE-2026-1489", "cve_description": "A flaw was found in GLib. An integer overflow vulnerability in its Unicode case conversion implementation can lead to memory corruption. By processing specially crafted and extremely large Unicode strings, an attacker could trigger an undersized memory allocation, resulting in out-of-bounds writes. This could cause applications utilizing GLib for string conversion to crash or become unstable.", "cve_priority": "medium", "cve_public_date": "2026-01-27 15:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: integer overflow in Base64 encoding", " - debian/patches/CVE-2026-1484-1.patch: use gsize to prevent potential", " overflow in glib/gbase64.c.", " - debian/patches/CVE-2026-1484-2.patch: ensure that the out value is", " within allocated size in glib/gbase64.c.", " - CVE-2026-1484", " * SECURITY UPDATE: buffer underflow via header length", " - debian/patches/CVE-2026-1485.patch: do not overflow if header is", " longer than MAXINT in gio/gcontenttype.c.", " - CVE-2026-1485", " * SECURITY UPDATE: integer overflow via Unicode case conversion", " - debian/patches/CVE-2026-1489-1.patch: use size_t for output_marks", " length in glib/guniprop.c.", " - debian/patches/CVE-2026-1489-2.patch: do not convert size_t to gint", " in glib/guniprop.c.", " - debian/patches/CVE-2026-1489-3.patch: ensure we do not overflow size", " in glib/guniprop.c.", " - debian/patches/CVE-2026-1489-4.patch: add test debug information when", " parsing input files in glib/tests/unicode.c.", " - CVE-2026-1489", "" ], "package": "glib2.0", "version": "2.80.0-6ubuntu3.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 28 Jan 2026 12:53:07 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libgnutls30t64", "from_version": { "source_package_name": "gnutls28", "source_package_version": "3.8.3-1.1ubuntu3.4", "version": "3.8.3-1.1ubuntu3.4" }, "to_version": { "source_package_name": "gnutls28", "source_package_version": "3.8.3-1.1ubuntu3.5", "version": "3.8.3-1.1ubuntu3.5" }, "cves": [ { "cve": "CVE-2025-14831", "url": "https://ubuntu.com/security/CVE-2025-14831", "cve_description": "A flaw was found in GnuTLS. This vulnerability allows a denial of service (DoS) by excessive CPU (Central Processing Unit) and memory consumption via specially crafted malicious certificates containing a large number of name constraints and subject alternative names (SANs).", "cve_priority": "medium", "cve_public_date": "2026-02-09 15:16:00 UTC" }, { "cve": "CVE-2025-9820", "url": "https://ubuntu.com/security/CVE-2025-9820", "cve_description": "A flaw was found in the GnuTLS library, specifically in the gnutls_pkcs11_token_init() function that handles PKCS#11 token initialization. When a token label longer than expected is processed, the function writes past the end of a fixed-size stack buffer. This programming error can cause the application using GnuTLS to crash or, in certain conditions, be exploited for code execution. As a result, systems or applications relying on GnuTLS may be vulnerable to a denial of service or local privilege escalation attacks.", "cve_priority": "low", "cve_public_date": "2026-01-26 20:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-14831", "url": "https://ubuntu.com/security/CVE-2025-14831", "cve_description": "A flaw was found in GnuTLS. This vulnerability allows a denial of service (DoS) by excessive CPU (Central Processing Unit) and memory consumption via specially crafted malicious certificates containing a large number of name constraints and subject alternative names (SANs).", "cve_priority": "medium", "cve_public_date": "2026-02-09 15:16:00 UTC" }, { "cve": "CVE-2025-9820", "url": "https://ubuntu.com/security/CVE-2025-9820", "cve_description": "A flaw was found in the GnuTLS library, specifically in the gnutls_pkcs11_token_init() function that handles PKCS#11 token initialization. When a token label longer than expected is processed, the function writes past the end of a fixed-size stack buffer. This programming error can cause the application using GnuTLS to crash or, in certain conditions, be exploited for code execution. As a result, systems or applications relying on GnuTLS may be vulnerable to a denial of service or local privilege escalation attacks.", "cve_priority": "low", "cve_public_date": "2026-01-26 20:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: DoS via malicious certificates", " - debian/patches/CVE-2025-14831-*.patch: rework processing algorithms", " to exhibit better performance characteristics in", " lib/x509/name_constraints.c, tests/name-constraints-ip.c.", " - CVE-2025-14831", " * SECURITY UPDATE: stack overflow via long token label", " - debian/patches/CVE-2025-9820.patch: avoid stack overwrite when", " initializing a token in lib/pkcs11_write.c, tests/Makefile.am,", " tests/pkcs11/long-label.c.", " - CVE-2025-9820", "" ], "package": "gnutls28", "version": "3.8.3-1.1ubuntu3.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 10 Feb 2026 11:09:12 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libldap2", "from_version": { "source_package_name": "openldap", "source_package_version": "2.6.7+dfsg-1~exp1ubuntu8.2", "version": "2.6.7+dfsg-1~exp1ubuntu8.2" }, "to_version": { "source_package_name": "openldap", "source_package_version": "2.6.10+dfsg-0ubuntu0.24.04.1", "version": "2.6.10+dfsg-0ubuntu0.24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2127665, 2125685, 2121816 ], "changes": [ { "cves": [], "log": [ "", " * New upstream version (LP: #2127665):", " - 2.6.10:", " - Added slapd microsecond timestamp format for local logging (ITS#10140)", " - Fixed libldap ldap_result behavior with LDAP_MSG_RECEIVED (ITS#10229)", " - Fixed lloadd handling of starttls critical (ITS#10323)", " - Fixed slapd syncrepl when used with slapo-rwm (ITS#10290)", " - Fixed slapd regression with certain searches (ITS#10307)", " - Fixed slapo-autoca olcAutoCAserverClass object (ITS#10288)", " - Fixed slapo-pcache caching behaviors (ITS#10270)", "", " - 2.6.9:", " - Fixed libldap TLS connection timeout handling (ITS#8047)", " - Fixed libldap GnuTLS incompatible pointer type (ITS#10253)", " - Fixed libldap OpenSSL set_ciphersuite error handling (ITS#10223)", " - Fixed libldap to check for OpenSSL EVP_Digest* failure (ITS#10224)", " - Fixed slapd cn=config disallowed modification of cn=schema (ITS#10256)", " - Fixed slapd syncrepl assert during refresh at shutdown (ITS#10232)", " - Fixed slapd syncrepl retry state during refreshDone (ITS#10234)", " - Fixed slapd-ldap use of multi-precision add for op counters (ITS#10237)", " - Fixed slapd-mdb idl intersection (ITS#10233)", " - Fixed slapd-wt idl intersection (ITS#10233)", " - Fixed slapo-memberof to omit dynamic values (ITS#10230)", " - Fixed slapo-nestgroup leak in nestgroup_memberFilter (ITS#10249)", " - Fixed slapo-translucent regression with subordinate databases (ITS#10248)", " - Fixed slapo-translucent regression when requesting attributes (ITS#10272)", " - Fixed slappw-argon2 defaults to be more secure (ITS#9827)", "", " - 2.6.8:", " - Fixed libldap exit handling with OpenSSL3 again (ITS#9952)", " - Fixed libldap OpenSSL channel binding digest (ITS#10216)", " - Fixed slapd handling of large uid/gids peercred auth (ITS#10211)", " - Fixed slapd-asyncmeta/meta target structure allocations (ITS#10197)", " - Fixed slapd-meta with dynlist (ITS#10164)", " - Fixed slapd-meta binds when proxying internal op (ITS#10165)", " - Added slapo-nestgroup overlay (ITS#10161)", " - Added slapo-memberof 'addcheck' option (ITS#10167)", " - Fixed slapo-accesslog startup initialization (ITS#10170)", " - Fixed slapo-constraint double free on invalid attr (ITS#10204)", " - Fixed slapo-dynlist with abandoned operations (ITS#10044)", " - Build", " - Fixed build with gcc14.x (ITS#10166)", " - Fixed back-perl with clang15 (ITS#10177)", " - Fixed to reduce systemd dependencies (ITS#10214)", " - Contrib", " - Added slapo-alias contrib module (ITS#10104, ITS#10182)", " - Fixed slapo-autogroup to work with slapo-dynlist (ITS#10185)", " - Fixed smbk5pwd implicit function declaration (ITS#10206)", " - Documentation", " - Fixed slapo-memberof exattr requirements (ITS#7400)", " - Fixed slapo-memberof is no longer deprecated (ITS#7400)", "", " - d/p/lp2090806...TLS-...timeout-handling: removed", " [upstream in 2.6.9]", " - d/p/smbk5pwd-implicit-declaration: removed", " [upstream in 2.6.8]", " - d/p/64-bit-time-t-compat: adjust for 2.6.10", " - d/slapd.{install,manpages}: install new slapo-nestgroup overlay", " [from 2.6.8+dfsg-1~exp2]", " - d/slapd.manpages: add slapo-autogroup overlay", " [from 2.6.8+dfsg-1~exp2]", " * pbkdf2 iteration configuration support (LP: #2125685)", " - d/p/lp2125685-pbkdf2-configurable-rounds: make iterations configurable", " - d/p/lp2125685-pbkdf2-fix-iteration-arg: fix iteration argument index", " - d/t/pbkdf2-contrib: test if pbkdf2 hashing rounds are adjustable", " * Enable build of ppm password quality check module (LP: #2121816)", " - d/rules: build ppm password quality module", " - d/p/contrib-makefiles: add build adjustment from 2.6.9+dfsg-1~exp1 (#1039740)", " - d/p/ppm-cross: cross-build patch from 2.6.8+dfsg-1~exp1 (#1079533)", " - d/t/ppm-contrib: test ppm password quality module", " - d/control: add build dependency on libcrack2-dev for ppm", " - d/slapd-contrib.{examples,install,manpages}: add ppm", "" ], "package": "openldap", "version": "2.6.10+dfsg-0ubuntu0.24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2127665, 2125685, 2121816 ], "author": "Jonas Jelten ", "date": "Tue, 23 Sep 2025 18:26:39 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpng16-16t64", "from_version": { "source_package_name": "libpng1.6", "source_package_version": "1.6.43-5ubuntu0.3", "version": "1.6.43-5ubuntu0.3" }, "to_version": { "source_package_name": "libpng1.6", "source_package_version": "1.6.43-5ubuntu0.5", "version": "1.6.43-5ubuntu0.5" }, "cves": [ { "cve": "CVE-2026-25646", "url": "https://ubuntu.com/security/CVE-2026-25646", "cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.55, an out-of-bounds read vulnerability exists in the png_set_quantize() API function. When the function is called with no histogram and the number of colors in the palette is more than twice the maximum supported by the user's display, certain palettes will cause the function to enter into an infinite loop that reads past the end of an internal heap-allocated buffer. The images that trigger this vulnerability are valid per the PNG specification. This vulnerability is fixed in 1.6.55.", "cve_priority": "medium", "cve_public_date": "2026-02-10 18:16:00 UTC" }, { "cve": "CVE-2025-2816", "url": "https://ubuntu.com/security/CVE-2025-2816", "cve_description": "", "cve_priority": "n/a", "cve_public_date": "" }, { "cve": "CVE-2025-28162", "url": "https://ubuntu.com/security/CVE-2025-28162", "cve_description": "Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via the pngimage with AddressSanitizer (ASan), the program leaks memory in various locations, eventually leading to high memory usage and causing the program to become unresponsive", "cve_priority": "medium", "cve_public_date": "2026-01-27 16:16:00 UTC" }, { "cve": "CVE-2025-28164", "url": "https://ubuntu.com/security/CVE-2025-28164", "cve_description": "Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via png_create_read_struct() function.", "cve_priority": "medium", "cve_public_date": "2026-01-27 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-25646", "url": "https://ubuntu.com/security/CVE-2026-25646", "cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.55, an out-of-bounds read vulnerability exists in the png_set_quantize() API function. When the function is called with no histogram and the number of colors in the palette is more than twice the maximum supported by the user's display, certain palettes will cause the function to enter into an infinite loop that reads past the end of an internal heap-allocated buffer. The images that trigger this vulnerability are valid per the PNG specification. This vulnerability is fixed in 1.6.55.", "cve_priority": "medium", "cve_public_date": "2026-02-10 18:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: OOB read in png_set_quantize()", " - debian/patches/CVE-2026-25646.patch: fix a heap buffer overflow in", " pngrtran.c.", " - CVE-2026-25646", "" ], "package": "libpng1.6", "version": "1.6.43-5ubuntu0.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Feb 2026 09:27:12 -0500" }, { "cves": [ { "cve": "CVE-2025-2816", "url": "https://ubuntu.com/security/CVE-2025-2816", "cve_description": "", "cve_priority": "n/a", "cve_public_date": "" }, { "cve": "CVE-2025-28162", "url": "https://ubuntu.com/security/CVE-2025-28162", "cve_description": "Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via the pngimage with AddressSanitizer (ASan), the program leaks memory in various locations, eventually leading to high memory usage and causing the program to become unresponsive", "cve_priority": "medium", "cve_public_date": "2026-01-27 16:16:00 UTC" }, { "cve": "CVE-2025-28164", "url": "https://ubuntu.com/security/CVE-2025-28164", "cve_description": "Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via png_create_read_struct() function.", "cve_priority": "medium", "cve_public_date": "2026-01-27 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: DoS via buffer overflow caused by memory leaks", " - debian/patches/CVE-2025-2816x.patch: clean up on user/internal errors", " in contrib/libtests/pngimage.c, pngerror.c.", " - CVE-2025-28162", " - CVE-2025-28164", "" ], "package": "libpng1.6", "version": "1.6.43-5ubuntu0.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 29 Jan 2026 11:18:41 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.12-minimal", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.10", "version": "3.12.3-1ubuntu0.10" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "cves": [ { "cve": "CVE-2025-11468", "url": "https://ubuntu.com/security/CVE-2025-11468", "cve_description": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-12084", "url": "https://ubuntu.com/security/CVE-2025-12084", "cve_description": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.", "cve_priority": "medium", "cve_public_date": "2025-12-03 19:15:00 UTC" }, { "cve": "CVE-2025-13837", "url": "https://ubuntu.com/security/CVE-2025-13837", "cve_description": "When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues", "cve_priority": "medium", "cve_public_date": "2025-12-01 18:16:00 UTC" }, { "cve": "CVE-2025-15282", "url": "https://ubuntu.com/security/CVE-2025-15282", "cve_description": "User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0672", "url": "https://ubuntu.com/security/CVE-2026-0672", "cve_description": "When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-11468", "url": "https://ubuntu.com/security/CVE-2025-11468", "cve_description": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-12084", "url": "https://ubuntu.com/security/CVE-2025-12084", "cve_description": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.", "cve_priority": "medium", "cve_public_date": "2025-12-03 19:15:00 UTC" }, { "cve": "CVE-2025-13837", "url": "https://ubuntu.com/security/CVE-2025-13837", "cve_description": "When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues", "cve_priority": "medium", "cve_public_date": "2025-12-01 18:16:00 UTC" }, { "cve": "CVE-2025-15282", "url": "https://ubuntu.com/security/CVE-2025-15282", "cve_description": "User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0672", "url": "https://ubuntu.com/security/CVE-2026-0672", "cve_description": "When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Header injection in email messages where addresses are not", " sanitized.", " - debian/patches/CVE-2025-11468.patch: Add escape parentheses and backslash", " in Lib/email/_header_value_parser.py. Add test in", " Lib/test/test_email/test__header_value_parser.py.", " - CVE-2025-11468", " * SECURITY UPDATE: Quadratic algorithm when building excessively nested XML", " documents.", " - debian/patches/CVE-2025-12084-*.patch: Remove _in_document and replace", " with node.ownerDocument in Lib/xml/dom/minidom.py. Set self.ownerDocument", " to None in Lib/xml/dom/minidom.py. Add test in Lib/test/test_minidom.py.", " - CVE-2025-12084", " * SECURITY UPDATE: OOM and denial of service when opening malicious plist", " file.", " - debian/patches/CVE-2025-13837.patch: Add _MIN_READ_BUF_SIZE and _read", " with checks in Lib/plistlib.py. Add test in Lib/test/test_plistlib.py.", " - CVE-2025-13837", " * SECURITY UPDATE: Header injection in user controlled data URLs in urllib.", " - debian/patches/CVE-2025-15282.patch: Add control character checks in", " Lib/urllib/request.py. Add test in Lib/test/test_urllib.py.", " * SECURITY UPDATE: Command injection through user controlled commands in", " imaplib.", " - debian/patches/CVE-2025-15366.patch: Add _control_chars and checks in", " Lib/imaplib.py. Add test in Lib/test/test_imaplib.py.", " * SECURITY UPDATE: Command injection through user controlled commands in", " poplib.", " - debian/patches/CVE-2025-15367.patch: Add control character regex check", " in Lib/poplib.py. Add test in Lib/test/test_poplib.py.", " - CVE-2025-15367", " * SECURITY UPDATE: HTTP header injection in user controlled cookie values.", " - debian/patches/CVE-2026-0672.patch: Add _control_characters_re and", " checks in Lib/http/cookies.py. Add test in Lib/test/test_http_cookies.py.", " - CVE-2026-0672", " * SECURITY UPDATE: HTTP header injection in user controlled headers and", " values with newlines.", " - debian/patches/CVE-2026-0865.patch: Add _control_chars_re and check in", " Lib/wsgiref/headers.py. Add test in Lib/test/support/__init__.py and", " Lib/test/test_wsgiref.py.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.11", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Thu, 22 Jan 2026 17:27:42 -0330" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.12-stdlib", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.10", "version": "3.12.3-1ubuntu0.10" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "cves": [ { "cve": "CVE-2025-11468", "url": "https://ubuntu.com/security/CVE-2025-11468", "cve_description": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-12084", "url": "https://ubuntu.com/security/CVE-2025-12084", "cve_description": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.", "cve_priority": "medium", "cve_public_date": "2025-12-03 19:15:00 UTC" }, { "cve": "CVE-2025-13837", "url": "https://ubuntu.com/security/CVE-2025-13837", "cve_description": "When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues", "cve_priority": "medium", "cve_public_date": "2025-12-01 18:16:00 UTC" }, { "cve": "CVE-2025-15282", "url": "https://ubuntu.com/security/CVE-2025-15282", "cve_description": "User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0672", "url": "https://ubuntu.com/security/CVE-2026-0672", "cve_description": "When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-11468", "url": "https://ubuntu.com/security/CVE-2025-11468", "cve_description": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-12084", "url": "https://ubuntu.com/security/CVE-2025-12084", "cve_description": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.", "cve_priority": "medium", "cve_public_date": "2025-12-03 19:15:00 UTC" }, { "cve": "CVE-2025-13837", "url": "https://ubuntu.com/security/CVE-2025-13837", "cve_description": "When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues", "cve_priority": "medium", "cve_public_date": "2025-12-01 18:16:00 UTC" }, { "cve": "CVE-2025-15282", "url": "https://ubuntu.com/security/CVE-2025-15282", "cve_description": "User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0672", "url": "https://ubuntu.com/security/CVE-2026-0672", "cve_description": "When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Header injection in email messages where addresses are not", " sanitized.", " - debian/patches/CVE-2025-11468.patch: Add escape parentheses and backslash", " in Lib/email/_header_value_parser.py. Add test in", " Lib/test/test_email/test__header_value_parser.py.", " - CVE-2025-11468", " * SECURITY UPDATE: Quadratic algorithm when building excessively nested XML", " documents.", " - debian/patches/CVE-2025-12084-*.patch: Remove _in_document and replace", " with node.ownerDocument in Lib/xml/dom/minidom.py. Set self.ownerDocument", " to None in Lib/xml/dom/minidom.py. Add test in Lib/test/test_minidom.py.", " - CVE-2025-12084", " * SECURITY UPDATE: OOM and denial of service when opening malicious plist", " file.", " - debian/patches/CVE-2025-13837.patch: Add _MIN_READ_BUF_SIZE and _read", " with checks in Lib/plistlib.py. Add test in Lib/test/test_plistlib.py.", " - CVE-2025-13837", " * SECURITY UPDATE: Header injection in user controlled data URLs in urllib.", " - debian/patches/CVE-2025-15282.patch: Add control character checks in", " Lib/urllib/request.py. Add test in Lib/test/test_urllib.py.", " * SECURITY UPDATE: Command injection through user controlled commands in", " imaplib.", " - debian/patches/CVE-2025-15366.patch: Add _control_chars and checks in", " Lib/imaplib.py. Add test in Lib/test/test_imaplib.py.", " * SECURITY UPDATE: Command injection through user controlled commands in", " poplib.", " - debian/patches/CVE-2025-15367.patch: Add control character regex check", " in Lib/poplib.py. Add test in Lib/test/test_poplib.py.", " - CVE-2025-15367", " * SECURITY UPDATE: HTTP header injection in user controlled cookie values.", " - debian/patches/CVE-2026-0672.patch: Add _control_characters_re and", " checks in Lib/http/cookies.py. Add test in Lib/test/test_http_cookies.py.", " - CVE-2026-0672", " * SECURITY UPDATE: HTTP header injection in user controlled headers and", " values with newlines.", " - debian/patches/CVE-2026-0865.patch: Add _control_chars_re and check in", " Lib/wsgiref/headers.py. Add test in Lib/test/support/__init__.py and", " Lib/test/test_wsgiref.py.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.11", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Thu, 22 Jan 2026 17:27:42 -0330" } ], "notes": null, "is_version_downgrade": false }, { "name": "libstdc++6", "from_version": { "source_package_name": "gcc-14", "source_package_version": "14.2.0-4ubuntu2~24.04", "version": "14.2.0-4ubuntu2~24.04" }, "to_version": { "source_package_name": "gcc-14", "source_package_version": "14.2.0-4ubuntu2~24.04.1", "version": "14.2.0-4ubuntu2~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2101084 ], "changes": [ { "cves": [], "log": [ "", " * d/p/pr118976.diff: Fix memory corruption when executing 256-bit", " Scalable Vector Extensions code on 128-bit CPUs (LP: #2101084).", "" ], "package": "gcc-14", "version": "14.2.0-4ubuntu2~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2101084 ], "author": "Vladimir Petko ", "date": "Fri, 19 Dec 2025 10:36:50 +1300" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-90.91", "version": "6.8.0-90.91" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-100.100", "version": "6.8.0-100.100" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 2128721 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-100.100", "" ], "package": "linux-meta", "version": "6.8.0-100.100", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Tue, 13 Jan 2026 15:42:40 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-98.98", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "", " * missing transitionals for intel-iotg kernels (LP: #2128721)", " - [Packaging] Transition intel-iotg to hwe-24.04", "" ], "package": "linux-meta", "version": "6.8.0-98.98", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013, 2128721 ], "author": "Stefan Bader ", "date": "Fri, 09 Jan 2026 14:34:43 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "python-apt-common", "from_version": { "source_package_name": "python-apt", "source_package_version": "2.7.7ubuntu5.1", "version": "2.7.7ubuntu5.1" }, "to_version": { "source_package_name": "python-apt", "source_package_version": "2.7.7ubuntu5.2", "version": "2.7.7ubuntu5.2" }, "cves": [], "launchpad_bugs_fixed": [ 2138617 ], "changes": [ { "cves": [], "log": [ "", " * Mirror list update for 24.04.4 (LP: #2138617)", "" ], "package": "python-apt", "version": "2.7.7ubuntu5.2", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2138617 ], "author": "Florent 'Skia' Jacquet ", "date": "Mon, 19 Jan 2026 11:38:23 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-apt", "from_version": { "source_package_name": "python-apt", "source_package_version": "2.7.7ubuntu5.1", "version": "2.7.7ubuntu5.1" }, "to_version": { "source_package_name": "python-apt", "source_package_version": "2.7.7ubuntu5.2", "version": "2.7.7ubuntu5.2" }, "cves": [], "launchpad_bugs_fixed": [ 2138617 ], "changes": [ { "cves": [], "log": [ "", " * Mirror list update for 24.04.4 (LP: #2138617)", "" ], "package": "python-apt", "version": "2.7.7ubuntu5.2", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2138617 ], "author": "Florent 'Skia' Jacquet ", "date": "Mon, 19 Jan 2026 11:38:23 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-distupgrade", "from_version": { "source_package_name": "ubuntu-release-upgrader", "source_package_version": "1:24.04.27", "version": "1:24.04.27" }, "to_version": { "source_package_name": "ubuntu-release-upgrader", "source_package_version": "1:24.04.28", "version": "1:24.04.28" }, "cves": [], "launchpad_bugs_fixed": [ 2138637 ], "changes": [ { "cves": [], "log": [ "", " * Run pre-build.sh: updating mirrors for point release (LP: #2138637)", "" ], "package": "ubuntu-release-upgrader", "version": "1:24.04.28", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2138637 ], "author": "Florent 'Skia' Jacquet ", "date": "Mon, 19 Jan 2026 16:31:44 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.12", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.10", "version": "3.12.3-1ubuntu0.10" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "cves": [ { "cve": "CVE-2025-11468", "url": "https://ubuntu.com/security/CVE-2025-11468", "cve_description": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-12084", "url": "https://ubuntu.com/security/CVE-2025-12084", "cve_description": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.", "cve_priority": "medium", "cve_public_date": "2025-12-03 19:15:00 UTC" }, { "cve": "CVE-2025-13837", "url": "https://ubuntu.com/security/CVE-2025-13837", "cve_description": "When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues", "cve_priority": "medium", "cve_public_date": "2025-12-01 18:16:00 UTC" }, { "cve": "CVE-2025-15282", "url": "https://ubuntu.com/security/CVE-2025-15282", "cve_description": "User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0672", "url": "https://ubuntu.com/security/CVE-2026-0672", "cve_description": "When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-11468", "url": "https://ubuntu.com/security/CVE-2025-11468", "cve_description": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-12084", "url": "https://ubuntu.com/security/CVE-2025-12084", "cve_description": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.", "cve_priority": "medium", "cve_public_date": "2025-12-03 19:15:00 UTC" }, { "cve": "CVE-2025-13837", "url": "https://ubuntu.com/security/CVE-2025-13837", "cve_description": "When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues", "cve_priority": "medium", "cve_public_date": "2025-12-01 18:16:00 UTC" }, { "cve": "CVE-2025-15282", "url": "https://ubuntu.com/security/CVE-2025-15282", "cve_description": "User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0672", "url": "https://ubuntu.com/security/CVE-2026-0672", "cve_description": "When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Header injection in email messages where addresses are not", " sanitized.", " - debian/patches/CVE-2025-11468.patch: Add escape parentheses and backslash", " in Lib/email/_header_value_parser.py. Add test in", " Lib/test/test_email/test__header_value_parser.py.", " - CVE-2025-11468", " * SECURITY UPDATE: Quadratic algorithm when building excessively nested XML", " documents.", " - debian/patches/CVE-2025-12084-*.patch: Remove _in_document and replace", " with node.ownerDocument in Lib/xml/dom/minidom.py. Set self.ownerDocument", " to None in Lib/xml/dom/minidom.py. Add test in Lib/test/test_minidom.py.", " - CVE-2025-12084", " * SECURITY UPDATE: OOM and denial of service when opening malicious plist", " file.", " - debian/patches/CVE-2025-13837.patch: Add _MIN_READ_BUF_SIZE and _read", " with checks in Lib/plistlib.py. Add test in Lib/test/test_plistlib.py.", " - CVE-2025-13837", " * SECURITY UPDATE: Header injection in user controlled data URLs in urllib.", " - debian/patches/CVE-2025-15282.patch: Add control character checks in", " Lib/urllib/request.py. Add test in Lib/test/test_urllib.py.", " * SECURITY UPDATE: Command injection through user controlled commands in", " imaplib.", " - debian/patches/CVE-2025-15366.patch: Add _control_chars and checks in", " Lib/imaplib.py. Add test in Lib/test/test_imaplib.py.", " * SECURITY UPDATE: Command injection through user controlled commands in", " poplib.", " - debian/patches/CVE-2025-15367.patch: Add control character regex check", " in Lib/poplib.py. Add test in Lib/test/test_poplib.py.", " - CVE-2025-15367", " * SECURITY UPDATE: HTTP header injection in user controlled cookie values.", " - debian/patches/CVE-2026-0672.patch: Add _control_characters_re and", " checks in Lib/http/cookies.py. Add test in Lib/test/test_http_cookies.py.", " - CVE-2026-0672", " * SECURITY UPDATE: HTTP header injection in user controlled headers and", " values with newlines.", " - debian/patches/CVE-2026-0865.patch: Add _control_chars_re and check in", " Lib/wsgiref/headers.py. Add test in Lib/test/support/__init__.py and", " Lib/test/test_wsgiref.py.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.11", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Thu, 22 Jan 2026 17:27:42 -0330" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.12-minimal", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.10", "version": "3.12.3-1ubuntu0.10" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "cves": [ { "cve": "CVE-2025-11468", "url": "https://ubuntu.com/security/CVE-2025-11468", "cve_description": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-12084", "url": "https://ubuntu.com/security/CVE-2025-12084", "cve_description": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.", "cve_priority": "medium", "cve_public_date": "2025-12-03 19:15:00 UTC" }, { "cve": "CVE-2025-13837", "url": "https://ubuntu.com/security/CVE-2025-13837", "cve_description": "When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues", "cve_priority": "medium", "cve_public_date": "2025-12-01 18:16:00 UTC" }, { "cve": "CVE-2025-15282", "url": "https://ubuntu.com/security/CVE-2025-15282", "cve_description": "User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0672", "url": "https://ubuntu.com/security/CVE-2026-0672", "cve_description": "When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-11468", "url": "https://ubuntu.com/security/CVE-2025-11468", "cve_description": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-12084", "url": "https://ubuntu.com/security/CVE-2025-12084", "cve_description": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.", "cve_priority": "medium", "cve_public_date": "2025-12-03 19:15:00 UTC" }, { "cve": "CVE-2025-13837", "url": "https://ubuntu.com/security/CVE-2025-13837", "cve_description": "When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues", "cve_priority": "medium", "cve_public_date": "2025-12-01 18:16:00 UTC" }, { "cve": "CVE-2025-15282", "url": "https://ubuntu.com/security/CVE-2025-15282", "cve_description": "User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0672", "url": "https://ubuntu.com/security/CVE-2026-0672", "cve_description": "When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Header injection in email messages where addresses are not", " sanitized.", " - debian/patches/CVE-2025-11468.patch: Add escape parentheses and backslash", " in Lib/email/_header_value_parser.py. Add test in", " Lib/test/test_email/test__header_value_parser.py.", " - CVE-2025-11468", " * SECURITY UPDATE: Quadratic algorithm when building excessively nested XML", " documents.", " - debian/patches/CVE-2025-12084-*.patch: Remove _in_document and replace", " with node.ownerDocument in Lib/xml/dom/minidom.py. Set self.ownerDocument", " to None in Lib/xml/dom/minidom.py. Add test in Lib/test/test_minidom.py.", " - CVE-2025-12084", " * SECURITY UPDATE: OOM and denial of service when opening malicious plist", " file.", " - debian/patches/CVE-2025-13837.patch: Add _MIN_READ_BUF_SIZE and _read", " with checks in Lib/plistlib.py. Add test in Lib/test/test_plistlib.py.", " - CVE-2025-13837", " * SECURITY UPDATE: Header injection in user controlled data URLs in urllib.", " - debian/patches/CVE-2025-15282.patch: Add control character checks in", " Lib/urllib/request.py. Add test in Lib/test/test_urllib.py.", " * SECURITY UPDATE: Command injection through user controlled commands in", " imaplib.", " - debian/patches/CVE-2025-15366.patch: Add _control_chars and checks in", " Lib/imaplib.py. Add test in Lib/test/test_imaplib.py.", " * SECURITY UPDATE: Command injection through user controlled commands in", " poplib.", " - debian/patches/CVE-2025-15367.patch: Add control character regex check", " in Lib/poplib.py. Add test in Lib/test/test_poplib.py.", " - CVE-2025-15367", " * SECURITY UPDATE: HTTP header injection in user controlled cookie values.", " - debian/patches/CVE-2026-0672.patch: Add _control_characters_re and", " checks in Lib/http/cookies.py. Add test in Lib/test/test_http_cookies.py.", " - CVE-2026-0672", " * SECURITY UPDATE: HTTP header injection in user controlled headers and", " values with newlines.", " - debian/patches/CVE-2026-0865.patch: Add _control_chars_re and check in", " Lib/wsgiref/headers.py. Add test in Lib/test/support/__init__.py and", " Lib/test/test_wsgiref.py.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.11", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Thu, 22 Jan 2026 17:27:42 -0330" } ], "notes": null, "is_version_downgrade": false }, { "name": "ubuntu-release-upgrader-core", "from_version": { "source_package_name": "ubuntu-release-upgrader", "source_package_version": "1:24.04.27", "version": "1:24.04.27" }, "to_version": { "source_package_name": "ubuntu-release-upgrader", "source_package_version": "1:24.04.28", "version": "1:24.04.28" }, "cves": [], "launchpad_bugs_fixed": [ 2138637 ], "changes": [ { "cves": [], "log": [ "", " * Run pre-build.sh: updating mirrors for point release (LP: #2138637)", "" ], "package": "ubuntu-release-upgrader", "version": "1:24.04.28", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2138637 ], "author": "Florent 'Skia' Jacquet ", "date": "Mon, 19 Jan 2026 16:31:44 +0100" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-image-6.8.0-100-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-90.91", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-100.100", "version": "6.8.0-100.100" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-90.91", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-90.91", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Tue, 18 Nov 2025 12:46:03 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-89.90", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-89.90", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 14 Nov 2025 18:08:07 +0100" } ], "notes": "linux-image-6.8.0-100-generic version '6.8.0-100.100' (source package linux-signed version '6.8.0-100.100') was added. linux-image-6.8.0-100-generic version '6.8.0-100.100' has the same source package name, linux-signed, as removed package linux-image-6.8.0-90-generic. As such we can use the source package version of the removed package, '6.8.0-90.91', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-6.8.0-100-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-90.91", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-100.100", "version": "6.8.0-100.100" }, "cves": [ { "cve": "CVE-2025-39779", "url": "https://ubuntu.com/security/CVE-2025-39779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39759", "url": "https://ubuntu.com/security/CVE-2025-39759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix race between quota disable and quota rescan ioctl There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info->qgroup_tree rbtree. This happens as follows: 1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan(); 2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A); 3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock; 4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free. Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas were already disabled.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39705", "url": "https://ubuntu.com/security/CVE-2025-39705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a Null pointer dereference vulnerability [Why] A null pointer dereference vulnerability exists in the AMD display driver's (DC module) cleanup function dc_destruct(). When display control context (dc->ctx) construction fails (due to memory allocation failure), this pointer remains NULL. During subsequent error handling when dc_destruct() is called, there's no NULL check before dereferencing the perf_trace member (dc->ctx->perf_trace), causing a kernel null pointer dereference crash. [How] Check if dc->ctx is non-NULL before dereferencing. (Updated commit text and removed unnecessary error message) (cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39707", "url": "https://ubuntu.com/security/CVE-2025-39707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities HUBBUB structure is not initialized on DCE hardware, so check if it is NULL to avoid null dereference while accessing amdgpu_dm_capabilities file in debugfs.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39712", "url": "https://ubuntu.com/security/CVE-2025-39712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval Getting / Setting the frame interval using the V4L2 subdev pad ops get_frame_interval/set_frame_interval causes a deadlock, as the subdev state is locked in the [1] but also in the driver itself. In [2] it's described that the caller is responsible to acquire and release the lock in this case. Therefore, acquiring the lock in the driver is wrong. Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval() and mt9m114_ifp_set_frame_interval(). [1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129 [2] Documentation/driver-api/media/v4l2-subdev.rst", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-38686", "url": "https://ubuntu.com/security/CVE-2025-38686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry When UFFDIO_MOVE encounters a migration PMD entry, it proceeds with obtaining a folio and accessing it even though the entry is swp_entry_t. Add the missing check and let split_huge_pmd() handle migration entries. While at it also remove unnecessary folio check. [surenb@google.com: remove extra folio check, per David]", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38703", "url": "https://ubuntu.com/security/CVE-2025-38703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Make dma-fences compliant with the safe access rules Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a sync_fence fd) which will then cause an use- after-free on subsequent access. To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence. For the timeline name we simply make the queue be freed via kfree_rcu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39746", "url": "https://ubuntu.com/security/CVE-2025-39746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: shutdown driver when hardware is unreliable In rare cases, ath10k may lose connection with the PCIe bus due to some unknown reasons, which could further lead to system crashes during resuming due to watchdog timeout: ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardware ath10k_pci 0000:01:00.0: already restarting ath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11 ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11 ieee80211 phy0: PM: **** DPM device timeout **** Call Trace: panic+0x125/0x315 dpm_watchdog_set+0x54/0x54 dpm_watchdog_handler+0x57/0x57 call_timer_fn+0x31/0x13c At this point, all WMI commands will timeout and attempt to restart device. So set a threshold for consecutive restart failures. If the threshold is exceeded, consider the hardware is unreliable and all ath10k operations should be skipped to avoid system crash. fail_cont_count and pending_recovery are atomic variables, and do not involve complex conditional logic. Therefore, even if recovery check and reconfig complete are executed concurrently, the recovery mechanism will not be broken. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39747", "url": "https://ubuntu.com/security/CVE-2025-39747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Add error handling for krealloc in metadata setup Function msm_ioctl_gem_info_set_metadata() now checks for krealloc failure and returns -ENOMEM, avoiding potential NULL pointer dereference. Explicitly avoids __GFP_NOFAIL due to deadlock risks and allocation constraints. Patchwork: https://patchwork.freedesktop.org/patch/661235/", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38704", "url": "https://ubuntu.com/security/CVE-2025-38704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer access In the preparation stage of CPU online, if the corresponding the rdp's->nocb_cb_kthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocb_cb_kthread pointer, but this rdp's->nocb_gp_rdp and rdp's->rdp_gp->nocb_gp_kthread is still valid. This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthread_unpark() will access invalid rdp's->nocb_cb_kthread pointer. This commit therefore use rdp's->nocb_gp_kthread instead of rdp_gp's->nocb_gp_kthread for safety check.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39748", "url": "https://ubuntu.com/security/CVE-2025-39748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38705", "url": "https://ubuntu.com/security/CVE-2025-38705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix null pointer access Writing a string without delimiters (' ', '\\n', '\\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38710", "url": "https://ubuntu.com/security/CVE-2025-38710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38722", "url": "https://ubuntu.com/security/CVE-2025-38722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: habanalabs: fix UAF in export_dmabuf() As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). habanalabs export_dmabuf() calls it and then proceeds to access the objects destroyed on close. In particular, it grabs an extra reference to another struct file that will be dropped as part of ->release() for ours; that \"will be\" is actually \"might have already been\". Fix that by reserving descriptor before anything else and do fd_install() only when everything had been set up. As a side benefit, we no longer have the failure exit with file already created, but reference to underlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet; unlike dma_buf_fd(), fd_install() can't fail.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38732", "url": "https://ubuntu.com/security/CVE-2025-38732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject: don't leak dst refcount for loopback packets recent patches to add a WARN() when replacing skb dst entry found an old bug: WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline] WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline] WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234 [..] Call Trace: nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline] .. This is because blamed commit forgot about loopback packets. Such packets already have a dst_entry attached, even at PRE_ROUTING stage. Instead of checking hook just check if the skb already has a route attached to it.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39766", "url": "https://ubuntu.com/security/CVE-2025-39766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit The following setup can trigger a WARNING in htb_activate due to the condition: !cl->leaf.q->q.qlen tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 \\ htb rate 64bit tc qdisc add dev lo parent 1:1 handle f: \\ cake memlimit 1b ping -I lo -f -c1 -s64 -W0.001 127.0.0.1 This is because the low memlimit leads to a low buffer_limit, which causes packet dropping. However, cake_enqueue still returns NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an empty child qdisc. We should return NET_XMIT_CN when packets are dropped from the same tin and flow. I do not believe return value of NET_XMIT_CN is necessary for packet drops in the case of ack filtering, as that is meant to optimize performance, not to signal congestion.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38734", "url": "https://ubuntu.com/security/CVE-2025-38734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF on smcsk after smc_listen_out() BPF CI testing report a UAF issue: [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: error_code(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ? __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590 The direct cause of this issue is that after smc_listen_out_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows: smc_listen_work | userspace ----------------------------------------------------------------- lock_sock(sk) | smc_listen_out_connected() | | \\- smc_listen_out | | | \\- release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | \\- socket->sk = NULL; /* newclcsock->sk is NULL now */ SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk)) Since smc_listen_out_connected() will not fail, simply swapping the order of the code can easily fix this issue.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-38735", "url": "https://ubuntu.com/security/CVE-2025-38735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: prevent ethtool ops after shutdown A crash can occur if an ethtool operation is invoked after shutdown() is called. shutdown() is invoked during system shutdown to stop DMA operations without performing expensive deallocations. It is discouraged to unregister the netdev in this path, so the device may still be visible to userspace and kernel helpers. In gve, shutdown() tears down most internal data structures. If an ethtool operation is dispatched after shutdown(), it will dereference freed or NULL pointers, leading to a kernel panic. While graceful shutdown normally quiesces userspace before invoking the reboot syscall, forced shutdowns (as observed on GCP VMs) can still trigger this path. Fix by calling netif_device_detach() in shutdown(). This marks the device as detached so the ethtool ioctl handler will skip dispatching operations to the driver.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39673", "url": "https://ubuntu.com/security/CVE-2025-39673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix race conditions in ppp_fill_forward_path ppp_fill_forward_path() has two race conditions: 1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic. 2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels. Fix these by using a lockless RCU approach: - Use list_first_or_null_rcu() to safely test and access the first list entry. - Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal. - Check for a NULL pch->chan before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39770", "url": "https://ubuntu.com/security/CVE-2025-39770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM When performing Generic Segmentation Offload (GSO) on an IPv6 packet that contains extension headers, the kernel incorrectly requests checksum offload if the egress device only advertises NETIF_F_IPV6_CSUM feature, which has a strict contract: it supports checksum offload only for plain TCP or UDP over IPv6 and explicitly does not support packets with extension headers. The current GSO logic violates this contract by failing to disable the feature for packets with extension headers, such as those used in GREoIPv6 tunnels. This violation results in the device being asked to perform an operation it cannot support, leading to a `skb_warn_bad_offload` warning and a collapse of network throughput. While device TSO/USO is correctly bypassed in favor of software GSO for these packets, the GSO stack must be explicitly told not to request checksum offload. Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4 in gso_features_check if the IPv6 header contains extension headers to compute checksum in software. The exception is a BIG TCP extension, which, as stated in commit 68e068cabd2c6c53 (\"net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets\"): \"The feature is only enabled on devices that support BIG TCP TSO. The header is only present for PF_PACKET taps like tcpdump, and not transmitted by physical devices.\" kernel log output (truncated): WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140 ... Call Trace: skb_checksum_help+0x12a/0x1f0 validate_xmit_skb+0x1a3/0x2d0 validate_xmit_skb_list+0x4f/0x80 sch_direct_xmit+0x1a2/0x380 __dev_xmit_skb+0x242/0x670 __dev_queue_xmit+0x3fc/0x7f0 ip6_finish_output2+0x25e/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel] ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre] dev_hard_start_xmit+0x63/0x1c0 __dev_queue_xmit+0x6d0/0x7f0 ip6_finish_output2+0x214/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 inet6_csk_xmit+0xeb/0x150 __tcp_transmit_skb+0x555/0xa80 tcp_write_xmit+0x32a/0xe90 tcp_sendmsg_locked+0x437/0x1110 tcp_sendmsg+0x2f/0x50 ... skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00 skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00 skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00 skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00 skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9 skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01 skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39675", "url": "https://ubuntu.com/security/CVE-2025-39675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session() The function mod_hdcp_hdcp1_create_session() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference. Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null. This is similar to the commit c3e9826a2202 (\"drm/amd/display: Add null pointer check for get_first_active_display()\"). (cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39772", "url": "https://ubuntu.com/security/CVE-2025-39772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/hisilicon/hibmc: fix the hibmc loaded failed bug When hibmc loaded failed, the driver use hibmc_unload to free the resource, but the mutexes in mode.config are not init, which will access an NULL pointer. Just change goto statement to return, because hibnc_hw_init() doesn't need to free anything.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38676", "url": "https://ubuntu.com/security/CVE-2025-38676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Avoid stack buffer overflow from kernel cmdline While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of \"acpiid\" if the \"str\" argument is maximum length.", "cve_priority": "medium", "cve_public_date": "2025-08-26 13:15:00 UTC" }, { "cve": "CVE-2025-39676", "url": "https://ubuntu.com/security/CVE-2025-39676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla4xxx: Prevent a potential error pointer dereference The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error, but qla4xxx_ep_connect() returns error pointers. Propagating the error pointers will lead to an Oops in the caller, so change the error pointers to NULL.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39773", "url": "https://ubuntu.com/security/CVE-2025-39773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix soft lockup in br_multicast_query_expired() When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > \t/sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a (\"net: bridge: mcast: add and enforce query interval minimum\"), add check for the query interval maximum to fix this issue.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39679", "url": "https://ubuntu.com/security/CVE-2025-39679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor(). When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39681", "url": "https://ubuntu.com/security/CVE-2025-39681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper Since 923f3a2b48bd (\"x86/resctrl: Query LLC monitoring properties once during boot\") resctrl_cpu_detect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code. This triggers a division by zero fault during early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale. Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ]", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39687", "url": "https://ubuntu.com/security/CVE-2025-39687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: as73211: Ensure buffer holes are zeroed Given that the buffer is copied to a kfifo that ultimately user space can read, ensure we zero it.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39683", "url": "https://ubuntu.com/security/CVE-2025-39683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Limit access to parser->buffer when trace_get_user failed When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered: BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165 CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39801", "url": "https://ubuntu.com/security/CVE-2025-39801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Remove WARN_ON for device endpoint command timeouts This commit addresses a rarely observed endpoint command timeout which causes kernel panic due to warn when 'panic_on_warn' is enabled and unnecessary call trace prints when 'panic_on_warn' is disabled. It is seen during fast software-controlled connect/disconnect testcases. The following is one such endpoint command timeout that we observed: 1. Connect ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd 2. Disconnect ========== ->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmd In the issue scenario, in Exynos platforms, we observed that control transfers for the previous connect have not yet been completed and end transfer command sent as a part of the disconnect sequence and processing of USB_ENDPOINT_HALT feature request from the host timeout. This maybe an expected scenario since the controller is processing EP commands sent as a part of the previous connect. It maybe better to remove WARN_ON in all places where device endpoint commands are sent to avoid unnecessary kernel panic due to warn.", "cve_priority": "medium", "cve_public_date": "2025-09-15 13:15:00 UTC" }, { "cve": "CVE-2025-39684", "url": "https://ubuntu.com/security/CVE-2025-39684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl() syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernel buffer is allocated to hold `insn->n` samples (each of which is an `unsigned int`). For some instruction types, `insn->n` samples are copied back to user-space, unless an error code is being returned. The problem is that not all the instruction handlers that need to return data to userspace fill in the whole `insn->n` samples, so that there is an information leak. There is a similar syzbot report for `do_insnlist_ioctl()`, although it does not have a reproducer for it at the time of writing. One culprit is `insn_rw_emulate_bits()` which is used as the handler for `INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have a specific handler for that instruction, but do have an `INSN_BITS` handler. For `INSN_READ` it only fills in at most 1 sample, so if `insn->n` is greater than 1, the remaining `insn->n - 1` samples copied to userspace will be uninitialized kernel data. Another culprit is `vm80xx_ai_insn_read()` in the \"vm80xx\" driver. It never returns an error, even if it fails to fill the buffer. Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure that uninitialized parts of the allocated buffer are zeroed before handling each instruction. Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fix replaced the call to `kmalloc_array()` with `kcalloc()`, but it is not always necessary to clear the whole buffer.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39685", "url": "https://ubuntu.com/security/CVE-2025-39685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: pcl726: Prevent invalid irq number The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob. Added an interrupt number check to prevent users from passing in an irq number that was too large. If `it->options[1]` is 31, then `1 << it->options[1]` is still invalid because it shifts a 1-bit into the sign bit (which is UB in C). Possible solutions include reducing the upper bound on the `it->options[1]` value to 30 or lower, or using `1U << it->options[1]`. The old code would just not attempt to request the IRQ if the `options[1]` value were invalid. And it would still configure the device without interrupts even if the call to `request_irq` returned an error. So it would be better to combine this test with the test below.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39686", "url": "https://ubuntu.com/security/CVE-2025-39686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Make insn_rw_emulate_bits() do insn->n samples The `insn_rw_emulate_bits()` function is used as a default handler for `INSN_READ` instructions for subdevices that have a handler for `INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a default handler for `INSN_WRITE` instructions for subdevices that have a handler for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the `INSN_READ` or `INSN_WRITE` instruction handling with a constructed `INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE` instructions are supposed to be able read or write multiple samples, indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currently only handles a single sample. For `INSN_READ`, the comedi core will copy `insn->n` samples back to user-space. (That triggered KASAN kernel-infoleak errors when `insn->n` was greater than 1, but that is being fixed more generally elsewhere in the comedi core.) Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or return an error, to conform to the general expectation for `INSN_READ` and `INSN_WRITE` handlers.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39689", "url": "https://ubuntu.com/security/CVE-2025-39689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Also allocate and copy hash for reading of filter files Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs. Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39691", "url": "https://ubuntu.com/security/CVE-2025-39691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/buffer: fix use-after-free when call bh_read() helper There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio \t do_mpage_readpage \t ntfs_get_block_vbo \t bh_read \t submit_bh \t wait_on_buffer(bh); \t blk_complete_reqs \t\t\t\t scsi_io_completion \t\t\t\t scsi_end_request \t\t\t\t blk_update_request \t\t\t\t end_bio_bh_io_sync \t\t\t\t\t end_buffer_read_sync \t\t\t\t\t __end_buffer_read_notouch \t\t\t\t\t unlock_buffer wait_on_buffer(bh);--> return will return to caller \t\t\t\t\t put_bh \t\t\t\t\t --> trigger stack-out-of-bounds In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun. If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch().", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39692", "url": "https://ubuntu.com/security/CVE-2025-39692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy() We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()! Otherwise already existing connections try to use smb_direct_wq as a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39788", "url": "https://ubuntu.com/security/CVE-2025-39788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE On Google gs101, the number of UTP transfer request slots (nutrs) is 32, and in this case the driver ends up programming the UTRL_NEXUS_TYPE incorrectly as 0. This is because the left hand side of the shift is 1, which is of type int, i.e. 31 bits wide. Shifting by more than that width results in undefined behaviour. Fix this by switching to the BIT() macro, which applies correct type casting as required. This ensures the correct value is written to UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift warning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int' For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE write.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39693", "url": "https://ubuntu.com/security/CVE-2025-39693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid a NULL pointer dereference [WHY] Although unlikely drm_atomic_get_new_connector_state() or drm_atomic_get_old_connector_state() can return NULL. [HOW] Check returns before dereference. (cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39694", "url": "https://ubuntu.com/security/CVE-2025-39694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Fix SCCB present check Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation. If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping. Fix this by introducing a function that handles the NULL case before address translation.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39776", "url": "https://ubuntu.com/security/CVE-2025-39776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/debug_vm_pgtable: clear page table entries at destroy_args() The mm/debug_vm_pagetable test allocates manually page table entries for the tests it runs, using also its manually allocated mm_struct. That in itself is ok, but when it exits, at destroy_args() it fails to clear those entries with the *_clear functions. The problem is that leaves stale entries. If another process allocates an mm_struct with a pgd at the same address, it may end up running into the stale entry. This is happening in practice on a debug kernel with CONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extra debugging I added (it prints a warning trace if pgtables_bytes goes negative, in addition to the warning at check_mm() function): [ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000 [ 2.539366] kmem_cache info [ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508 [ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e (...) [ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0 [ 2.552816] Modules linked in: [ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY [ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries [ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90 [ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug) [ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a [ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0 [ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001 [ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff [ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000 [ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb [ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0 [ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000 [ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001 [ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760 [ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0 [ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0 [ 2.553199] Call Trace: [ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable) [ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0 [ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570 [ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650 [ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290 [ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0 [ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870 [ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150 [ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50 [ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0 [ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec (...) [ 2.558892] ---[ end trace 0000000000000000 ]--- [ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1 [ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144 Here the modprobe process ended up with an allocated mm_struct from the mm_struct slab that was used before by the debug_vm_pgtable test. That is not a problem, since the mm_stru ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38681", "url": "https://ubuntu.com/security/CVE-2025-38681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd() Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39800", "url": "https://ubuntu.com/security/CVE-2025-39800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: abort transaction on unexpected eb generation at btrfs_copy_root() If we find an unexpected generation for the extent buffer we are cloning at btrfs_copy_root(), we just WARN_ON() and don't error out and abort the transaction, meaning we allow to persist metadata with an unexpected generation. Instead of warning only, abort the transaction and return -EUCLEAN.", "cve_priority": "medium", "cve_public_date": "2025-09-15 13:15:00 UTC" }, { "cve": "CVE-2025-38684", "url": "https://ubuntu.com/security/CVE-2025-38684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: use old 'nbands' while purging unused classes Shuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify() after recent changes from Lion [2]. The problem is: in ets_qdisc_change() we purge unused DWRR queues; the value of 'q->nbands' is the new one, and the cleanup should be done with the old one. The problem is here since my first attempts to fix ets_qdisc_change(), but it surfaced again after the recent qdisc len accounting fixes. Fix it purging idle DWRR queues before assigning a new value of 'q->nbands', so that all purge operations find a consistent configuration: - old 'q->nbands' because it's needed by ets_class_find() - old 'q->nstrict' because it's needed by ets_class_is_strict() BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary) Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021 RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80 Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <48> 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab RSP: 0018:ffffba186009f400 EFLAGS: 00010202 RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004 RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004 R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000 R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000 FS: 00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ets_class_qlen_notify+0x65/0x90 [sch_ets] qdisc_tree_reduce_backlog+0x74/0x110 ets_qdisc_change+0x630/0xa40 [sch_ets] __tc_modify_qdisc.constprop.0+0x216/0x7f0 tc_modify_qdisc+0x7c/0x120 rtnetlink_rcv_msg+0x145/0x3f0 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x245/0x390 netlink_sendmsg+0x21b/0x470 ____sys_sendmsg+0x39d/0x3d0 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x7d/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f2155114084 Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084 RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003 RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0 R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0 [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/ [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-21884", "url": "https://ubuntu.com/security/CVE-2025-21884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: better track kernel sockets lifetime While kernel sockets are dismantled during pernet_operations->exit(), their freeing can be delayed by any tx packets still held in qdisc or device queues, due to skb_set_owner_w() prior calls. This then trigger the following warning from ref_tracker_dir_exit() [1] To fix this, make sure that kernel sockets own a reference on net->passive. Add sk_net_refcnt_upgrade() helper, used whenever a kernel socket is converted to a refcounted one. [1] [ 136.263918][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at [ 136.263918][ T35] sk_alloc+0x2b3/0x370 [ 136.263918][ T35] inet6_create+0x6ce/0x10f0 [ 136.263918][ T35] __sock_create+0x4c0/0xa30 [ 136.263918][ T35] inet_ctl_sock_create+0xc2/0x250 [ 136.263918][ T35] igmp6_net_init+0x39/0x390 [ 136.263918][ T35] ops_init+0x31e/0x590 [ 136.263918][ T35] setup_net+0x287/0x9e0 [ 136.263918][ T35] copy_net_ns+0x33f/0x570 [ 136.263918][ T35] create_new_namespaces+0x425/0x7b0 [ 136.263918][ T35] unshare_nsproxy_namespaces+0x124/0x180 [ 136.263918][ T35] ksys_unshare+0x57d/0xa70 [ 136.263918][ T35] __x64_sys_unshare+0x38/0x40 [ 136.263918][ T35] do_syscall_64+0xf3/0x230 [ 136.263918][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 136.263918][ T35] [ 136.343488][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at [ 136.343488][ T35] sk_alloc+0x2b3/0x370 [ 136.343488][ T35] inet6_create+0x6ce/0x10f0 [ 136.343488][ T35] __sock_create+0x4c0/0xa30 [ 136.343488][ T35] inet_ctl_sock_create+0xc2/0x250 [ 136.343488][ T35] ndisc_net_init+0xa7/0x2b0 [ 136.343488][ T35] ops_init+0x31e/0x590 [ 136.343488][ T35] setup_net+0x287/0x9e0 [ 136.343488][ T35] copy_net_ns+0x33f/0x570 [ 136.343488][ T35] create_new_namespaces+0x425/0x7b0 [ 136.343488][ T35] unshare_nsproxy_namespaces+0x124/0x180 [ 136.343488][ T35] ksys_unshare+0x57d/0xa70 [ 136.343488][ T35] __x64_sys_unshare+0x38/0x40 [ 136.343488][ T35] do_syscall_64+0xf3/0x230 [ 136.343488][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-39701", "url": "https://ubuntu.com/security/CVE-2025-39701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: pfr_update: Fix the driver update version check The security-version-number check should be used rather than the runtime version check for driver updates. Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39702", "url": "https://ubuntu.com/security/CVE-2025-39702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39703", "url": "https://ubuntu.com/security/CVE-2025-39703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net, hsr: reject HSR frame if skb can't hold tag Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG): [ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0 [ 45.402911] Call Trace: [ 45.403105] [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [ 45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116] __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] This issue was found by syzkaller. The panic happens in br_dev_queue_push_xmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skb_push() call, there's not enough headroom and skb_push() panics. The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG). Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers. Alternative fix would be to check for enough headroom before skb_push() in br_dev_queue_push_xmit(). In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network. Further Details: In the reproducer, the following network interface chain is set up: ┌────────────────┐ ┌────────────────┐ │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘ To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39706", "url": "https://ubuntu.com/security/CVE-2025-39706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Destroy KFD debugfs after destroy KFD wq Since KFD proc content was moved to kernel debugfs, we can't destroy KFD debugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq prior to kfd_debugfs_fini to fix a kernel NULL pointer problem. It happens when /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini but kfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry); tries to remove /sys/kernel/debug/kfd/proc/ while /sys/kernel/debug/kfd is already gone. It hangs the kernel by kernel NULL pointer. (cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39709", "url": "https://ubuntu.com/security/CVE-2025-39709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: protect against spurious interrupts during probe Make sure the interrupt handler is initialized before the interrupt is registered. If the IRQ is registered before hfi_create(), it's possible that an interrupt fires before the handler setup is complete, leading to a NULL dereference. This error condition has been observed during system boot on Rb3Gen2.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39710", "url": "https://ubuntu.com/security/CVE-2025-39710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: Add a check for packet size after reading from shared memory Add a check to ensure that the packet size does not exceed the number of available words after reading the packet header from shared memory. This ensures that the size provided by the firmware is safe to process and prevent potential out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39711", "url": "https://ubuntu.com/security/CVE-2025-39711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls Both the ACE and CSI driver are missing a mei_cldev_disable() call in their remove() function. This causes the mei_cl client to stay part of the mei_device->file_list list even though its memory is freed by mei_cl_bus_dev_release() calling kfree(cldev->cl). This leads to a use-after-free when mei_vsc_remove() runs mei_stop() which first removes all mei bus devices calling mei_ace_remove() and mei_csi_remove() followed by mei_cl_bus_dev_release() and then calls mei_cl_all_disconnect() which walks over mei_device->file_list dereferecing the just freed cldev->cl. And mei_vsc_remove() it self is run at shutdown because of the platform_device_unregister(tp->pdev) in vsc_tp_shutdown() When building a kernel with KASAN this leads to the following KASAN report: [ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNED_MODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] ... [ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei [ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc [ 106.635066] platform_remove (drivers/base/platform.c:1424) Add the missing mei_cldev_disable() calls so that the mei_cl gets removed from mei_device->file_list before it is freed to fix this.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39713", "url": "https://ubuntu.com/security/CVE-2025-39713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt() In the interrupt handler rain_interrupt(), the buffer full check on rain->buf_len is performed before acquiring rain->buf_lock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buf_len is concurrently accessed and modified in the work handler rain_irq_work_handler() under the same lock. Multiple interrupt invocations can race, with each reading buf_len before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buf_len beyond its capacity (DATA_SIZE) and causing a buffer overflow. Fix this bug by moving the spin_lock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spin_unlock() is added to the overflow path to correctly release the lock. This possible bug was found by an experimental static analysis tool developed by our team.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39714", "url": "https://ubuntu.com/security/CVE-2025-39714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: Lock resolution while streaming When an program is streaming (ffplay) and another program (qv4l2) changes the TV standard from NTSC to PAL, the kernel crashes due to trying to copy to unmapped memory. Changing from NTSC to PAL increases the resolution in the usbtv struct, but the video plane buffer isn't adjusted, so it overflows. [hverkuil: call vb2_is_busy instead of vb2_is_streaming]", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39715", "url": "https://ubuntu.com/security/CVE-2025-39715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Revise gateway LWS calls to probe user read access We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER). Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39716", "url": "https://ubuntu.com/security/CVE-2025-39716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Revise __get_user() to probe user read access Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call. Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed. Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39781", "url": "https://ubuntu.com/security/CVE-2025-39781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Drop WARN_ON_ONCE() from flush_cache_vmap I have observed warning to occassionally trigger.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39782", "url": "https://ubuntu.com/security/CVE-2025-39782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: prevent softlockup in jbd2_log_do_checkpoint() Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant. jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup. watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20 So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38677", "url": "https://ubuntu.com/security/CVE-2025-38677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-boundary access in dnode page As Jiaming Zhang reported: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x17e/0x800 mm/kasan/report.c:480 kasan_report+0x147/0x180 mm/kasan/report.c:593 data_blkaddr fs/f2fs/f2fs.h:3053 [inline] f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline] f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855 f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195 prepare_write_begin fs/f2fs/data.c:3395 [inline] f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594 generic_perform_write+0x2c7/0x910 mm/filemap.c:4112 f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline] f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x546/0xa90 fs/read_write.c:686 ksys_write+0x149/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is in the corrupted image, there is a dnode has the same node id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to access block address in dnode at offset 934, however it parses the dnode as inode node, so that get_dnode_addr() returns 360, then it tries to access page address from 360 + 934 * 4 = 4096 w/ 4 bytes. To fix this issue, let's add sanity check for node id of all direct nodes during f2fs_get_dnode_of_data().", "cve_priority": "medium", "cve_public_date": "2025-08-30 10:15:00 UTC" }, { "cve": "CVE-2025-39718", "url": "https://ubuntu.com/security/CVE-2025-39718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Validate length in packet header before skb_put() When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put().", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39783", "url": "https://ubuntu.com/security/CVE-2025-39783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix configfs group list head handling Doing a list_del() on the epf_group field of struct pci_epf_driver in pci_epf_remove_cfs() is not correct as this field is a list head, not a list entry. This list_del() call triggers a KASAN warning when an endpoint function driver which has a configfs attribute group is torn down: ================================================================== BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198 Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319 CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONE Hardware name: Radxa ROCK 5B (DT) Call trace: show_stack+0x2c/0x84 (C) dump_stack_lvl+0x70/0x98 print_report+0x17c/0x538 kasan_report+0xb8/0x190 __asan_report_store8_noabort+0x20/0x2c pci_epf_remove_cfs+0x17c/0x198 pci_epf_unregister_driver+0x18/0x30 nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf] __arm64_sys_delete_module+0x264/0x424 invoke_syscall+0x70/0x260 el0_svc_common.constprop.0+0xac/0x230 do_el0_svc+0x40/0x58 el0_svc+0x48/0xdc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ... Remove this incorrect list_del() call from pci_epf_remove_cfs().", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39719", "url": "https://ubuntu.com/security/CVE-2025-39719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: imu: bno055: fix OOB access of hw_xlate array Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c. In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array. By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39787", "url": "https://ubuntu.com/security/CVE-2025-39787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: qcom: mdt_loader: Ensure we don't read past the ELF header When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients. Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. e_phentsize and e_shentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39720", "url": "https://ubuntu.com/security/CVE-2025-39720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix refcount leak causing resource not released When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39721", "url": "https://ubuntu.com/security/CVE-2025-39721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - flush misc workqueue during device shutdown Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded. Since the driver uses a shared workqueue (`qat_misc_wq`) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50 To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded. Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39790", "url": "https://ubuntu.com/security/CVE-2025-39790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Detect events pointing to unexpected TREs When a remote device sends a completion event to the host, it contains a pointer to the consumed TRE. The host uses this pointer to process all of the TREs between it and the host's local copy of the ring's read pointer. This works when processing completion for chained transactions, but can lead to nasty results if the device sends an event for a single-element transaction with a read pointer that is multiple elements ahead of the host's read pointer. For instance, if the host accesses an event ring while the device is updating it, the pointer inside of the event might still point to an old TRE. If the host uses the channel's xfer_cb() to directly free the buffer pointed to by the TRE, the buffer will be double-freed. This behavior was observed on an ep that used upstream EP stack without 'commit 6f18d174b73d (\"bus: mhi: ep: Update read pointer only after buffer is written\")'. Where the device updated the events ring pointer before updating the event contents, so it left a window where the host was able to access the stale data the event pointed to, before the device had the chance to update them. The usual pattern was that the host received an event pointing to a TRE that is not immediately after the last processed one, so it got treated as if it was a chained transaction, processing all of the TREs in between the two read pointers. This commit aims to harden the host by ensuring transactions where the event points to a TRE that isn't local_rp + 1 are chained. [mani: added stable tag and reworded commit message]", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39724", "url": "https://ubuntu.com/security/CVE-2025-39724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39758", "url": "https://ubuntu.com/security/CVE-2025-39758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages Ever since commit c2ff29e99a76 (\"siw: Inline do_tcp_sendpages()\"), we have been doing this: static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset, size_t size) [...] /* Calculate the number of bytes we need to push, for this page * specifically */ size_t bytes = min_t(size_t, PAGE_SIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; /* Set the bvec pointing to the page, with len $bytes */ bvec_set_page(&bvec, page[i], bytes, offset); /* Set the iter to $size, aka the size of the whole sendpages (!!!) */ iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size); try_page_again: lock_sock(sk); /* Sendmsg with $size size (!!!) */ rv = tcp_sendmsg_locked(sk, &msg, size); This means we've been sending oversized iov_iters and tcp_sendmsg calls for a while. This has a been a benign bug because sendpage_ok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in iov_iter behavior between the MSG_SPLICE_PAGES and \"regular\" copy paths: (MSG_SPLICE_PAGES) skb_splice_from_iter iov_iter_extract_pages iov_iter_extract_bvec_pages uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere skb_splice_from_iter gets a \"short\" read (!MSG_SPLICE_PAGES) skb_copy_to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len = iter->count; iterate_bvec ... and we run off the bvecs Fix this by properly setting the iov_iter's byte count, plus sending the correct byte count to tcp_sendmsg_locked.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38679", "url": "https://ubuntu.com/security/CVE-2025-38679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: Fix OOB read due to missing payload bound check Currently, The event_seq_changed() handler processes a variable number of properties sent by the firmware. The number of properties is indicated by the firmware and used to iterate over the payload. However, the payload size is not being validated against the actual message length. This can lead to out-of-bounds memory access if the firmware provides a property count that exceeds the data available in the payload. Such a condition can result in kernel crashes or potential information leaks if memory beyond the buffer is accessed. Fix this by properly validating the remaining size of the payload before each property access and updating bounds accordingly as properties are parsed. This ensures that property parsing is safely bounded within the received message buffer and protects against malformed or malicious firmware behavior.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38680", "url": "https://ubuntu.com/security/CVE-2025-38680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() The buffer length check before calling uvc_parse_format() only ensured that the buffer has at least 3 bytes (buflen > 2), buf the function accesses buffer[3], requiring at least 4 bytes. This can lead to an out-of-bounds read if the buffer has exactly 3 bytes. Fix it by checking that the buffer has at least 4 bytes in uvc_parse_format().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39736", "url": "https://ubuntu.com/security/CVE-2025-39736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock When netpoll is enabled, calling pr_warn_once() while holding kmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock inversion with the netconsole subsystem. This occurs because pr_warn_once() may trigger netpoll, which eventually leads to __alloc_skb() and back into kmemleak code, attempting to reacquire kmemleak_lock. This is the path for the deadlock. mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem \t -> netpoll \t -> __alloc_skb \t\t -> __create_object \t\t -> raw_spin_lock_irqsave(&kmemleak_lock, flags); Fix this by setting a flag and issuing the pr_warn_once() after kmemleak_lock is released.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39737", "url": "https://ubuntu.com/security/CVE-2025-39737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup() A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134] The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000. The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects. As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38683", "url": "https://ubuntu.com/security/CVE-2025-38683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Fix panic during namespace deletion with VF The existing code move the VF NIC to new namespace when NETDEV_REGISTER is received on netvsc NIC. During deletion of the namespace, default_device_exit_batch() >> default_device_exit_net() is called. When netvsc NIC is moved back and registered to the default namespace, it automatically brings VF NIC back to the default namespace. This will cause the default_device_exit_net() >> for_each_netdev_safe loop unable to detect the list end, and hit NULL ptr: [ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0 [ 231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 231.450246] #PF: supervisor read access in kernel mode [ 231.450579] #PF: error_code(0x0000) - not-present page [ 231.450916] PGD 17b8a8067 P4D 0 [ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI [ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY [ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024 [ 231.452692] Workqueue: netns cleanup_net [ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0 [ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00 [ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246 [ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb [ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564 [ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000 [ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340 [ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340 [ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000 [ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0 [ 231.458434] Call Trace: [ 231.458600] [ 231.458777] ops_undo_list+0x100/0x220 [ 231.459015] cleanup_net+0x1b8/0x300 [ 231.459285] process_one_work+0x184/0x340 To fix it, move the ns change to a workqueue, and take rtnl_lock to avoid changing the netdev list when default_device_exit_net() is using it.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38685", "url": "https://ubuntu.com/security/CVE-2025-38685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix vmalloc out-of-bounds write in fast_imageblit This issue triggers when a userspace program does an ioctl FBIOPUT_CON2FBMAP by passing console number and frame buffer number. Ideally this maps console to frame buffer and updates the screen if console is visible. As part of mapping it has to do resize of console according to frame buffer info. if this resize fails and returns from vc_do_resize() and continues further. At this point console and new frame buffer are mapped and sets display vars. Despite failure still it continue to proceed updating the screen at later stages where vc_data is related to previous frame buffer and frame buffer info and display vars are mapped to new frame buffer and eventully leading to out-of-bounds write in fast_imageblit(). This bheviour is excepted only when fg_console is equal to requested console which is a visible console and updates screen with invalid struct references in fbcon_putcs().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39738", "url": "https://ubuntu.com/security/CVE-2025-39738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not allow relocation of partially dropped subvolumes [BUG] There is an internal report that balance triggered transaction abort, with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs] And btrfs check doesn't report anything wrong related to the extent tree. [CAUSE] The cause is a little complex, firstly the extent tree indeed doesn't have the backref for 594526208. The extent tree only have the following two backrefs around that bytenr on-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE But the such missing backref item is not an corruption on disk, as the offending delayed ref belongs to subvolume 934, and that subvolume is being dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229 And that offending tree block 594526208 is inside the dropped range of that subvolume. That explains why there is no backref item for that bytenr and why btrfs check is not reporting anything wrong. But this also shows another problem, as btrfs will do all the orphan subvolume cleanup at a read-write mount. So half-dropped subvolume should not exist after an RW mount, and balance itself is also exclusive to subvolume cleanup, meaning we shouldn't hit a subvolume half-dropped during relocation. The root cause is, there is no orphan item for this subvolume. In fact there are 5 subvolumes from around 2021 that have the same problem. It looks like the original report has some older kernels running, and caused those zombie subvolumes. Thankfully upstream commit 8d488a8c7ba2 (\"btrfs: fix subvolume/snapshot deletion not triggered on mount\") has long fixed the bug. [ENHANCEMENT] For repairing such old fs, btrfs-progs will be enhanced. Considering how delayed the problem will show up (at run delayed ref time) and at that time we have to abort transaction already, it is too late. Instead here we reject any half-dropped subvolume for reloc tree at the earliest time, preventing confusion and extra time wasted on debugging similar bugs.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38687", "url": "https://ubuntu.com/security/CVE-2025-38687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: fix race between polling and detaching syzbot reports a use-after-free in comedi in the below link, which is due to comedi gladly removing the allocated async area even though poll requests are still active on the wait_queue_head inside of it. This can cause a use-after-free when the poll entries are later triggered or removed, as the memory for the wait_queue_head has been freed. We need to check there are no tasks queued on any of the subdevices' wait queues before allowing the device to be detached by the `COMEDI_DEVCONFIG` ioctl. Tasks will read-lock `dev->attach_lock` before adding themselves to the subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl handler by write-locking `dev->attach_lock` before checking that all of the subdevices are safe to be deleted. This includes testing for any sleepers on the subdevices' wait queues. It remains locked until the device has been detached. This requires the `comedi_device_detach()` function to be refactored slightly, moving the bulk of it into new function `comedi_device_detach_locked()`. Note that the refactor of `comedi_device_detach()` results in `comedi_device_cancel_all()` now being called while `dev->attach_lock` is write-locked, which wasn't the case previously, but that does not matter. Thanks to Jens Axboe for diagnosing the problem and co-developing this patch.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39760", "url": "https://ubuntu.com/security/CVE-2025-39760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: config: Prevent OOB read in SS endpoint companion parsing usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size. Fix this up by checking the size first before looking at any of the fields in the descriptor.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38688", "url": "https://ubuntu.com/security/CVE-2025-38688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Prevent ALIGN() overflow When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either. Consolidate the two copies of this code under a single helper. This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39739", "url": "https://ubuntu.com/security/CVE-2025-39739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-qcom: Add SM6115 MDSS compatible Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot: arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed) ------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 \t\t... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38691", "url": "https://ubuntu.com/security/CVE-2025-38691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix uninited ptr deref in block/scsi layout The error occurs on the third attempt to encode extents. When function ext_tree_prepare_commit() reallocates a larger buffer to retry encoding extents, the \"layoutupdate_pages\" page array is initialized only after the retry loop. But ext_tree_free_commitdata() is called on every iteration and tries to put pages in the array, thus dereferencing uninitialized pointers. An additional problem is that there is no limit on the maximum possible buffer_size. When there are too many extents, the client may create a layoutcommit that is larger than the maximum possible RPC size accepted by the server. During testing, we observed two typical scenarios. First, one memory page for extents is enough when we work with small files, append data to the end of the file, or preallocate extents before writing. But when we fill a new large file without preallocating, the number of extents can be huge, and counting the number of written extents in ext_tree_encode_commit() does not help much. Since this number increases even more between unlocking and locking of ext_tree, the reallocated buffer may not be large enough again and again.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39795", "url": "https://ubuntu.com/security/CVE-2025-39795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: avoid possible overflow for chunk_sectors check in blk_stack_limits() In blk_stack_limits(), we check that the t->chunk_sectors value is a multiple of the t->physical_block_size value. However, by finding the chunk_sectors value in bytes, we may overflow the unsigned int which holds chunk_sectors, so change the check to be based on sectors.", "cve_priority": "medium", "cve_public_date": "2025-09-12 16:15:00 UTC" }, { "cve": "CVE-2025-38692", "url": "https://ubuntu.com/security/CVE-2025-38692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: add cluster chain loop check for dir An infinite loop may occur if the following conditions occur due to file system corruption. (1) Condition for exfat_count_dir_entries() to loop infinitely. - The cluster chain includes a loop. - There is no UNUSED entry in the cluster chain. (2) Condition for exfat_create_upcase_table() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and up-case table entry in the cluster chain of the root directory. (3) Condition for exfat_load_bitmap() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and bitmap entry in the cluster chain of the root directory. (4) Condition for exfat_find_dir_entry() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. (5) Condition for exfat_check_dir_empty() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. - All files and sub-directories under the directory are deleted. This commit adds checks to break the above infinite loop.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38693", "url": "https://ubuntu.com/security/CVE-2025-38693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serpar In w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar commit: commit 0ed554fd769a (\"media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()\")", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38694", "url": "https://ubuntu.com/security/CVE-2025-38694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb() In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar issue occurs when access msg[1].buf[0] and msg[1].buf[1]. Similar commit: commit 0ed554fd769a (\"media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()\")", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38695", "url": "https://ubuntu.com/security/CVE-2025-38695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may occur before sli4_hba.hdwqs are allocated. This may result in a null pointer dereference when attempting to take the abts_io_buf_list_lock for the first hardware queue. Fix by adding a null ptr check on phba->sli4_hba.hdwq and early return because this situation means there must have been an error during port initialization.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39742", "url": "https://ubuntu.com/security/CVE-2025-39742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask() The function divides number of online CPUs by num_core_siblings, and later checks the divider by zero. This implies a possibility to get and divide-by-zero runtime error. Fix it by moving the check prior to division. This also helps to save one indentation level.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38696", "url": "https://ubuntu.com/security/CVE-2025-38696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: Don't crash in stack_top() for tasks without ABI or vDSO Not all tasks have an ABI associated or vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL ABI pointer and crash. This can for example happen when using kunit: mips_stack_top+0x28/0xc0 arch_pick_mmap_layout+0x190/0x220 kunit_vm_mmap_init+0xf8/0x138 __kunit_add_resource+0x40/0xa8 kunit_vm_mmap+0x88/0xd8 usercopy_test_init+0xb8/0x240 kunit_try_run_case+0x5c/0x1a8 kunit_generic_run_threadfn_adapter+0x28/0x50 kthread+0x118/0x240 ret_from_kernel_thread+0x14/0x1c Only dereference the ABI point if it is set. The GIC page is also included as it is specific to the vDSO. Also move the randomization adjustment into the same conditional.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38697", "url": "https://ubuntu.com/security/CVE-2025-38697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: upper bound check of tree index in dbAllocAG When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38698", "url": "https://ubuntu.com/security/CVE-2025-38698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Regular file corruption check The reproducer builds a corrupted file on disk with a negative i_size value. Add a check when opening this file to avoid subsequent operation failures.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39743", "url": "https://ubuntu.com/security/CVE-2025-39743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: truncate good inode pages when hard link is 0 The fileset value of the inode copy from the disk by the reproducer is AGGR_RESERVED_I. When executing evict, its hard link number is 0, so its inode pages are not truncated. This causes the bugon to be triggered when executing clear_inode() because nrpages is greater than 0.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38699", "url": "https://ubuntu.com/security/CVE-2025-38699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Double-free fix When the bfad_im_probe() function fails during initialization, the memory pointed to by bfad->im is freed without setting bfad->im to NULL. Subsequently, during driver uninstallation, when the state machine enters the bfad_sm_stopping state and calls the bfad_im_probe_undo() function, it attempts to free the memory pointed to by bfad->im again, thereby triggering a double-free vulnerability. Set bfad->im to NULL if probing fails.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38700", "url": "https://ubuntu.com/security/CVE-2025-38700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown. Fix by setting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38701", "url": "https://ubuntu.com/security/CVE-2025-38701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data() when an inode had the INLINE_DATA_FL flag set but was missing the system.data extended attribute. Since this can happen due to a maiciouly fuzzed file system, we shouldn't BUG, but rather, report it as a corrupted file system. Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii ext4_create_inline_data() and ext4_inline_data_truncate().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38702", "url": "https://ubuntu.com/security/CVE-2025-38702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix potential buffer overflow in do_register_framebuffer() The current implementation may lead to buffer overflow when: 1. Unregistration creates NULL gaps in registered_fb[] 2. All array slots become occupied despite num_registered_fb < FB_MAX 3. The registration loop exceeds array bounds Add boundary check to prevent registered_fb[FB_MAX] access.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39744", "url": "https://ubuntu.com/security/CVE-2025-39744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu: Fix rcu_read_unlock() deadloop due to IRQ work During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up. This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly. irq_exit() __irq_exit_rcu() /* in_hardirq() returns false after this */ preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() \t tick_nohz_stop_sched_tick() \t trace_tick_stop() /* a bpf prog is hooked on this trace point */ \t\t __bpf_trace_tick_stop() \t\t bpf_trace_run2() \t\t\t rcu_read_unlock_special() /* will send a IPI to itself */ \t\t\t irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu); A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch: static inline void tick_irq_exit(void) { +\trcu_read_lock(); +\tWRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); +\trcu_read_unlock(); + [neeraj: Apply Frederic's suggested fix for PREEMPT_RT]", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39761", "url": "https://ubuntu.com/security/CVE-2025-39761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Decrement TID on RX peer frag setup error handling Currently, TID is not decremented before peer cleanup, during error handling path of ath12k_dp_rx_peer_frag_setup(). This could lead to out-of-bounds access in peer->rx_tid[]. Hence, add a decrement operation for TID, before peer cleanup to ensures proper cleanup and prevents out-of-bounds access issues when the RX peer frag setup fails. Found during code review. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39797", "url": "https://ubuntu.com/security/CVE-2025-39797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Duplicate SPI Handling The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses. This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops. According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol. Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable. Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.", "cve_priority": "medium", "cve_public_date": "2025-09-12 16:15:00 UTC" }, { "cve": "CVE-2025-39749", "url": "https://ubuntu.com/security/CVE-2025-39749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu: Protect ->defer_qs_iw_pending from data race On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest. In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally. The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat: ------------------------------------------------------------------------ BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [] __schedule+0x129/0xd70 softirqs last enabled at (0): [] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0 ------------------------------------------------------------------------ The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field. This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39750", "url": "https://ubuntu.com/security/CVE-2025-39750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Correct tid cleanup when tid setup fails Currently, if any error occurs during ath12k_dp_rx_peer_tid_setup(), the tid value is already incremented, even though the corresponding TID is not actually allocated. Proceed to ath12k_dp_rx_peer_tid_delete() starting from unallocated tid, which might leads to freeing unallocated TID and cause potential crash or out-of-bounds access. Hence, fix by correctly decrementing tid before cleanup to match only the successfully allocated TIDs. Also, remove tid-- from failure case of ath12k_dp_rx_peer_frag_setup(), as decrementing the tid before cleanup in loop will take care of this. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38706", "url": "https://ubuntu.com/security/CVE-2025-38706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime() snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39794", "url": "https://ubuntu.com/security/CVE-2025-39794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: tegra: Use I/O memcpy to write to IRAM Kasan crashes the kernel trying to check boundaries when using the normal memcpy.", "cve_priority": "medium", "cve_public_date": "2025-09-12 16:15:00 UTC" }, { "cve": "CVE-2025-39752", "url": "https://ubuntu.com/security/CVE-2025-39752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: rockchip: fix kernel hang during smp initialization In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39763", "url": "https://ubuntu.com/security/CVE-2025-39763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered If a synchronous error is detected as a result of user-space process triggering a 2-bit uncorrected error, the CPU will take a synchronous error exception such as Synchronous External Abort (SEA) on Arm64. The kernel will queue a memory_failure() work which poisons the related page, unmaps the page, and then sends a SIGBUS to the process, so that a system wide panic can be avoided. However, no memory_failure() work will be queued when abnormal synchronous errors occur. These errors can include situations like invalid PA, unexpected severity, no memory failure config support, invalid GUID section, etc. In such a case, the user-space process will trigger SEA again. This loop can potentially exceed the platform firmware threshold or even trigger a kernel hard lockup, leading to a system reboot. Fix it by performing a force kill if no memory_failure() work is queued for synchronous errors. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38707", "url": "https://ubuntu.com/security/CVE-2025-38707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add sanity check for file name The length of the file name should be smaller than the directory entry size.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38708", "url": "https://ubuntu.com/security/CVE-2025-38708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: add missing kref_get in handle_write_conflicts With `two-primaries` enabled, DRBD tries to detect \"concurrent\" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed. In handling \"superseeded\" writes, we forgot a kref_get, resulting in a premature drbd_destroy_device and use after free, and further to kernel crashes with symptoms. Relevance: No one should use DRBD as a random data generator, and apparently all users of \"two-primaries\" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node. Which means that other than for \"test cases\", this code path is never taken in real life. FYI, in DRBD 9, things are handled differently nowadays. We still detect \"write conflicts\", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39753", "url": "https://ubuntu.com/security/CVE-2025-39753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Set .migrate_folio in gfs2_{rgrp,meta}_aops Clears up the warning added in 7ee3647243e5 (\"migrate: Remove call to ->writepage\") that occurs in various xfstests, causing \"something found in dmesg\" failures. [ 341.136573] gfs2_meta_aops does not implement migrate_folio [ 341.136953] WARNING: CPU: 1 PID: 36 at mm/migrate.c:944 move_to_new_folio+0x2f8/0x300", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38711", "url": "https://ubuntu.com/security/CVE-2025-38711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: avoid deadlock when linking with ReplaceIfExists If smb2_create_link() is called with ReplaceIfExists set and the name does exist then a deadlock will happen. ksmbd_vfs_kern_path_locked() will return with success and the parent directory will be locked. ksmbd_vfs_remove_file() will then remove the file. ksmbd_vfs_link() will then be called while the parent is still locked. It will try to lock the same parent and will deadlock. This patch moves the ksmbd_vfs_kern_path_unlock() call to *before* ksmbd_vfs_link() and then simplifies the code, removing the file_present flag variable.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38712", "url": "https://ubuntu.com/security/CVE-2025-38712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file() When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplus_fill_super() assumes that the attributes file is not yet created, which later results in hitting BUG_ON() when hfsplus_create_attributes_file() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38713", "url": "https://ubuntu.com/security/CVE-2025-38713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc(): [ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 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 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38714", "url": "https://ubuntu.com/security/CVE-2025-38714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read() The hfsplus_bnode_read() method can trigger the issue: [ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0 [ 174.854305][ T9784] print_report+0xd0/0x660 [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610 [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854337][ T9784] kasan_report+0xc6/0x100 [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360 [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380 [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10 [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0 [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310 [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0 [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0 [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10 [ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10 [ 174.854436][ T9784] ? __asan_memset+0x23/0x50 [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320 [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10 [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0 [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0 [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10 [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10 [ 174.854525][ T9784] ? down_write+0x148/0x200 [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10 [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0 [ 174.854549][ T9784] do_unlinkat+0x490/0x670 [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10 [ 174.854565][ T9784] ? __might_fault+0xbc/0x130 [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550 [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110 [ 174.854592][ T9784] do_syscall_64+0xc9/0x480 [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasan_save_stack+0x20/0x40 [ 174.880082][ T9784] kasan_save_track+0x14/0x30 [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0 [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550 [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890 [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10 [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520 [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38715", "url": "https://ubuntu.com/security/CVE-2025-38715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: fix slab-out-of-bounds in hfs_bnode_read() This patch introduces is_bnode_offset_valid() method that checks the requested offset value. Also, it introduces check_and_correct_requested_length() method that checks and correct the requested length (if it is necessary). These methods are used in hfs_bnode_read(), hfs_bnode_write(), hfs_bnode_clear(), hfs_bnode_copy(), and hfs_bnode_move() with the goal to prevent the access out of allocated memory and triggering the crash.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38716", "url": "https://ubuntu.com/security/CVE-2025-38716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: fix general protection fault in hfs_find_init() The hfs_find_init() method can trigger the crash if tree pointer is NULL: [ 45.746290][ T9787] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] SMP KAI [ 45.747287][ T9787] KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] [ 45.748716][ T9787] CPU: 2 UID: 0 PID: 9787 Comm: repro Not tainted 6.16.0-rc3 #10 PREEMPT(full) [ 45.750250][ T9787] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 45.751983][ T9787] RIP: 0010:hfs_find_init+0x86/0x230 [ 45.752834][ T9787] Code: c1 ea 03 80 3c 02 00 0f 85 9a 01 00 00 4c 8d 6b 40 48 c7 45 18 00 00 00 00 48 b8 00 00 00 00 00 fc [ 45.755574][ T9787] RSP: 0018:ffffc90015157668 EFLAGS: 00010202 [ 45.756432][ T9787] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff819a4d09 [ 45.757457][ T9787] RDX: 0000000000000008 RSI: ffffffff819acd3a RDI: ffffc900151576e8 [ 45.758282][ T9787] RBP: ffffc900151576d0 R08: 0000000000000005 R09: 0000000000000000 [ 45.758943][ T9787] R10: 0000000080000000 R11: 0000000000000001 R12: 0000000000000004 [ 45.759619][ T9787] R13: 0000000000000040 R14: ffff88802c50814a R15: 0000000000000000 [ 45.760293][ T9787] FS: 00007ffb72734540(0000) GS:ffff8880cec64000(0000) knlGS:0000000000000000 [ 45.761050][ T9787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 45.761606][ T9787] CR2: 00007f9bd8225000 CR3: 000000010979a000 CR4: 00000000000006f0 [ 45.762286][ T9787] Call Trace: [ 45.762570][ T9787] [ 45.762824][ T9787] hfs_ext_read_extent+0x190/0x9d0 [ 45.763269][ T9787] ? submit_bio_noacct_nocheck+0x2dd/0xce0 [ 45.763766][ T9787] ? __pfx_hfs_ext_read_extent+0x10/0x10 [ 45.764250][ T9787] hfs_get_block+0x55f/0x830 [ 45.764646][ T9787] block_read_full_folio+0x36d/0x850 [ 45.765105][ T9787] ? __pfx_hfs_get_block+0x10/0x10 [ 45.765541][ T9787] ? const_folio_flags+0x5b/0x100 [ 45.765972][ T9787] ? __pfx_hfs_read_folio+0x10/0x10 [ 45.766415][ T9787] filemap_read_folio+0xbe/0x290 [ 45.766840][ T9787] ? __pfx_filemap_read_folio+0x10/0x10 [ 45.767325][ T9787] ? __filemap_get_folio+0x32b/0xbf0 [ 45.767780][ T9787] do_read_cache_folio+0x263/0x5c0 [ 45.768223][ T9787] ? __pfx_hfs_read_folio+0x10/0x10 [ 45.768666][ T9787] read_cache_page+0x5b/0x160 [ 45.769070][ T9787] hfs_btree_open+0x491/0x1740 [ 45.769481][ T9787] hfs_mdb_get+0x15e2/0x1fb0 [ 45.769877][ T9787] ? __pfx_hfs_mdb_get+0x10/0x10 [ 45.770316][ T9787] ? find_held_lock+0x2b/0x80 [ 45.770731][ T9787] ? lockdep_init_map_type+0x5c/0x280 [ 45.771200][ T9787] ? lockdep_init_map_type+0x5c/0x280 [ 45.771674][ T9787] hfs_fill_super+0x38e/0x720 [ 45.772092][ T9787] ? __pfx_hfs_fill_super+0x10/0x10 [ 45.772549][ T9787] ? snprintf+0xbe/0x100 [ 45.772931][ T9787] ? __pfx_snprintf+0x10/0x10 [ 45.773350][ T9787] ? do_raw_spin_lock+0x129/0x2b0 [ 45.773796][ T9787] ? find_held_lock+0x2b/0x80 [ 45.774215][ T9787] ? set_blocksize+0x40a/0x510 [ 45.774636][ T9787] ? sb_set_blocksize+0x176/0x1d0 [ 45.775087][ T9787] ? setup_bdev_super+0x369/0x730 [ 45.775533][ T9787] get_tree_bdev_flags+0x384/0x620 [ 45.775985][ T9787] ? __pfx_hfs_fill_super+0x10/0x10 [ 45.776453][ T9787] ? __pfx_get_tree_bdev_flags+0x10/0x10 [ 45.776950][ T9787] ? bpf_lsm_capable+0x9/0x10 [ 45.777365][ T9787] ? security_capable+0x80/0x260 [ 45.777803][ T9787] vfs_get_tree+0x8e/0x340 [ 45.778203][ T9787] path_mount+0x13de/0x2010 [ 45.778604][ T9787] ? kmem_cache_free+0x2b0/0x4c0 [ 45.779052][ T9787] ? __pfx_path_mount+0x10/0x10 [ 45.779480][ T9787] ? getname_flags.part.0+0x1c5/0x550 [ 45.779954][ T9787] ? putname+0x154/0x1a0 [ 45.780335][ T9787] __x64_sys_mount+0x27b/0x300 [ 45.780758][ T9787] ? __pfx___x64_sys_mount+0x10/0x10 [ 45.781232][ T9787] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38718", "url": "https://ubuntu.com/security/CVE-2025-38718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: linearize cloned gso packets in sctp_rcv A cloned head skb still shares these frag skbs in fraglist with the original head skb. It's not safe to access these frag skbs. syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline] and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] This patch fixes it by linearizing cloned gso packets in sctp_rcv().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38721", "url": "https://ubuntu.com/security/CVE-2025-38721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix refcount leak on table dump There is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ... While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone. This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0. This will then block the netns dismantle (or conntrack rmmod) as nf_conntrack_cleanup_net_list() will wait forever. This can be reproduced by running conntrack_resize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nf_conntrack_cleanup_net_list. One fix would to change this to: if (res < 0) { \t\tif (ct != last) \t nf_conntrack_get(&ct->ct_general); But this reference counting isn't needed in the first place. We can just store a cookie value instead. A followup patch will do the same for ctnetlink_exp_dump_table, it looks to me as if this has the same problem and like ctnetlink_dump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38614", "url": "https://ubuntu.com/security/CVE-2025-38614", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: Fix semi-unbounded recursion Ensure that epoll instances can never form a graph deeper than EP_MAX_NESTS+1 links. Currently, ep_loop_check_proc() ensures that the graph is loop-free and does some recursion depth checks, but those recursion depth checks don't limit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed (\"epoll: limit paths\"). Essentially, the current recursion depth check in ep_loop_check_proc() just serves to prevent it from recursing too deeply while checking for loops. A more thorough check is done in reverse_path_check() after the new graph edge has already been created; this checks, among other things, that no paths going upwards from any non-epoll file with a length of more than 5 edges exist. However, this check does not apply to non-epoll files. As a result, it is possible to recurse to a depth of at least roughly 500, tested on v6.15. (I am unsure if deeper recursion is possible; and this may have changed with commit 8c44dac8add7 (\"eventpoll: Fix priority inversion problem\").) To fix it: 1. In ep_loop_check_proc(), note the subtree depth of each visited node, and use subtree depths for the total depth calculation even when a subtree has already been visited. 2. Add ep_get_upwards_depth_proc() for similarly determining the maximum depth of an upwards walk. 3. In ep_loop_check(), use these values to limit the total path length between epoll nodes to EP_MAX_NESTS edges.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-39756", "url": "https://ubuntu.com/security/CVE-2025-39756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Prevent file descriptor table allocations exceeding INT_MAX When sysctl_nr_open is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 This happens because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning when the allocation is not flagged with __GFP_NOWARN. Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647) Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open 2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; } 3. Observe WARNING in dmesg at mm/slub.c:5027 systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that: 1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting 2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations 3. The resulting allocations (>8GB) are impractical and will always fail systemd's algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems, this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors. While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue. Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39798", "url": "https://ubuntu.com/security/CVE-2025-39798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix the setting of capabilities when automounting a new filesystem Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again.", "cve_priority": "medium", "cve_public_date": "2025-09-12 16:15:00 UTC" }, { "cve": "CVE-2025-38724", "url": "https://ubuntu.com/security/CVE-2025-38724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm() Lei Lu recently reported that nfsd4_setclientid_confirm() did not check the return value from get_client_locked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF. Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all. In the case where the unconfirmed client is expiring, just fail and return the result from get_client_locked().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38730", "url": "https://ubuntu.com/security/CVE-2025-38730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: commit partial buffers on retry Ring provided buffers are potentially only valid within the single execution context in which they were acquired. io_uring deals with this and invalidates them on retry. But on the networking side, if MSG_WAITALL is set, or if the socket is of the streaming type and too little was processed, then it will hang on to the buffer rather than recycle or commit it. This is problematic for two reasons: 1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid. 2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer. Fix this by disallowing partial retries from pinning a provided buffer across multiple executions, if ring provided buffers are used.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38725", "url": "https://ubuntu.com/security/CVE-2025-38725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: asix_devices: add phy_mask for ax88772 mdio bus Without setting phy_mask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phy_polling_mode() in phy_state_machine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoud the issue.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38728", "url": "https://ubuntu.com/security/CVE-2025-38728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb3: fix for slab out of bounds on mount to ksmbd With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39757", "url": "https://ubuntu.com/security/CVE-2025-39757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 cluster segment descriptors UAC3 class segment descriptors need to be verified whether their sizes match with the declared lengths and whether they fit with the allocated buffer sizes, too. Otherwise malicious firmware may lead to the unexpected OOB accesses.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38729", "url": "https://ubuntu.com/security/CVE-2025-38729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 power domain descriptors, too UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-40297", "url": "https://ubuntu.com/security/CVE-2025-40297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix use-after-free due to MST port state bypass syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot. [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40256", "url": "https://ubuntu.com/security/CVE-2025-40256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added In commit b441cf3f8c4b (\"xfrm: delete x->tunnel as we delete x\"), I missed the case where state creation fails between full initialization (->init_state has been called) and being inserted on the lists. In this situation, ->init_state has been called, so for IPcomp tunnels, the fallback tunnel has been created and added onto the lists, but the user state never gets added, because we fail before that. The user state doesn't go through __xfrm_state_delete, so we don't call xfrm_state_delete_tunnel for those states, and we end up leaking the FB tunnel. There are several codepaths affected by this: the add/update paths, in both net/key and xfrm, and the migrate code (xfrm_migrate, xfrm_state_migrate). A \"proper\" rollback of the init_state work would probably be doable in the add/update code, but for migrate it gets more complicated as multiple states may be involved. At some point, the new (not-inserted) state will be destroyed, so call xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states will have their fallback tunnel cleaned up during __xfrm_state_delete, which solves the issue that b441cf3f8c4b (and other patches before it) aimed at. All states (including FB tunnels) will be removed from the lists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40215", "url": "https://ubuntu.com/security/CVE-2025-40215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: delete x->tunnel as we delete x The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 (\"xfrm: destroy xfrm_state synchronously on net exit path\") is not complete. We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f (\"tcp: drop secpath at the same time as we currently drop dst\")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state. Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped. A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.", "cve_priority": "medium", "cve_public_date": "2025-12-04 13:15:00 UTC" }, { "cve": "CVE-2025-40214", "url": "https://ubuntu.com/security/CVE-2025-40214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Initialise scc_index in unix_add_edge(). Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c. Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments.", "cve_priority": "high", "cve_public_date": "2025-12-04 13:15:00 UTC" }, { "cve": "CVE-2025-38248", "url": "https://ubuntu.com/security/CVE-2025-38248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: mcast: Fix use-after-free during router port configuration The bridge maintains a global list of ports behind which a multicast router resides. The list is consulted during forwarding to ensure multicast packets are forwarded to these ports even if the ports are not member in the matching MDB entry. When per-VLAN multicast snooping is enabled, the per-port multicast context is disabled on each port and the port is removed from the global router port list: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 1 $ bridge -d mdb show | grep router However, the port can be re-added to the global list even when per-VLAN multicast snooping is enabled: # ip link set dev dummy1 type bridge_slave mcast_router 0 # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 Since commit 4b30ae9adb04 (\"net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions\"), when per-VLAN multicast snooping is enabled, multicast disablement on a port will disable the per-{port, VLAN} multicast contexts and not the per-port one. As a result, a port will remain in the global router port list even after it is deleted. This will lead to a use-after-free [1] when the list is traversed (when adding a new port to the list, for example): # ip link del dev dummy1 # ip link add name dummy2 up master br1 type dummy # ip link set dev dummy2 type bridge_slave mcast_router 2 Similarly, stale entries can also be found in the per-VLAN router port list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN} contexts are disabled on each port and the port is removed from the per-VLAN router port list: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 # ip link add name dummy1 up master br1 type dummy # bridge vlan add vid 2 dev dummy1 # bridge vlan global set vid 2 dev br1 mcast_snooping 1 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 0 $ bridge vlan global show dev br1 vid 2 | grep router However, the port can be re-added to the per-VLAN list even when per-VLAN multicast snooping is disabled: # bridge vlan set vid 2 dev dummy1 mcast_router 0 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 When the VLAN is deleted from the port, the per-{port, VLAN} multicast context will not be disabled since multicast snooping is not enabled on the VLAN. As a result, the port will remain in the per-VLAN router port list even after it is no longer member in the VLAN. This will lead to a use-after-free [2] when the list is traversed (when adding a new port to the list, for example): # ip link add name dummy2 up master br1 type dummy # bridge vlan add vid 2 dev dummy2 # bridge vlan del vid 2 dev dummy1 # bridge vlan set vid 2 dev dummy2 mcast_router 2 Fix these issues by removing the port from the relevant (global or per-VLAN) router port list in br_multicast_port_ctx_deinit(). The function is invoked during port deletion with the per-port multicast context and during VLAN deletion with the per-{port, VLAN} multicast context. Note that deleting the multicast router timer is not enough as it only takes care of the temporary multicast router states (1 or 3) and not the permanent one (2). [1] BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560 Write of size 8 at addr ffff888004a67328 by task ip/384 [...] Call Trace: dump_stack ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38619", "url": "https://ubuntu.com/security/CVE-2025-38619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: j721e-csi2rx: fix list_del corruption If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue. This causes the same buffer to be retried in the next iteration, resulting in a double list_del() and eventual list corruption. Fix this by removing the buffer from the queue before calling vb2_buffer_done() on error. This resolves a crash due to list_del corruption: [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048 [ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428) [ 37.850799] ------------[ cut here ]------------ [ 37.855424] kernel BUG at lib/list_debug.c:65! [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT) [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.914059] sp : ffff800080003db0 [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122 [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0 [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720 [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568 [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d [ 37.988832] Call trace: [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P) [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4 [ 38.001419] udma_vchan_complete+0x1e0/0x344 [ 38.005705] tasklet_action_common+0x118/0x310 [ 38.010163] tasklet_action+0x30/0x3c [ 38.013832] handle_softirqs+0x10c/0x2e0 [ 38.017761] __do_softirq+0x14/0x20 [ 38.021256] ____do_softirq+0x10/0x20 [ 38.024931] call_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] __irq_exit_rcu+0x130/0x15c [ 38.036909] irq_exit_rcu+0x10/0x20 [ 38.040403] el1_interrupt+0x38/0x60 [ 38.043987] el1h_64_irq_handler+0x18/0x24 [ 38.048091] el1h_64_irq+0x6c/0x70 [ 38.051501] default_idle_call+0x34/0xe0 (P) [ 38.055783] do_idle+0x1f8/0x250 [ 38.059021] cpu_startup_entry+0x34/0x3c [ 38.062951] rest_init+0xb4/0xc0 [ 38.066186] console_on_rootfs+0x0/0x6c [ 38.070031] __primary_switched+0x88/0x90 [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000) [ 38.080168] ---[ end trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.092197] SMP: stopping secondary CPUs [ 38.096139] Kernel Offset: disabled [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b [ 38.105202] Memory Limit: none [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38582", "url": "https://ubuntu.com/security/CVE-2025-38582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix double destruction of rsv_qp rsv_qp may be double destroyed in error flow, first in free_mr_init(), and then in hns_roce_exit(). Fix it by moving the free_mr_init() call into hns_roce_v2_init(). list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38585", "url": "https://ubuntu.com/security/CVE-2025-38585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() When gmin_get_config_var() calls efi.get_variable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow: 1. gmin_get_config_var() does not return the proper error code when efi.get_variable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure. 2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates *out_len to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmin_get_var_int() believes the call succeeded. The caller gmin_get_var_int() then performs: - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size - Due to bug #1, thinks call succeeded with len=required_size - Executes val[len] = 0, writing past end of 65-byte stack buffer This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution. Fix the bug by returning proper error codes from gmin_get_config_var() based on EFI status instead of stale 'ret' value. The gmin_get_var_int() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38593", "url": "https://ubuntu.com/security/CVE-2025-38593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()' Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race: 'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL; To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires: [ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-39732", "url": "https://ubuntu.com/security/CVE-2025-39732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to ieee80211_iterate_stations_atomic(). Note in this case the iterator is required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does not follow it as it might sleep. Consequently below warning is seen: BUG: sleeping function called from invalid context at wmi.c:304 Call Trace: dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.cold Change to ieee80211_iterate_stations_mtx() to fix this issue. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30", "cve_priority": "medium", "cve_public_date": "2025-09-07 16:15:00 UTC" }, { "cve": "CVE-2025-38595", "url": "https://ubuntu.com/security/CVE-2025-38595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen: fix UAF in dmabuf_exp_from_pages() [dma_buf_fd() fixes; no preferences regarding the tree it goes through - up to xen folks] As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the objects destroyed on close - starting with gntdev_dmabuf itself. Fix that by doing reserving descriptor before anything else and do fd_install() only when everything had been set up.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38660", "url": "https://ubuntu.com/security/CVE-2025-38660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: [ceph] parse_longname(): strrchr() expects NUL-terminated string ... and parse_longname() is not guaranteed that. That's the reason why it uses kmemdup_nul() to build the argument for kstrtou64(); the problem is, kstrtou64() is not the only thing that need it. Just get a NUL-terminated copy of the entire thing and be done with that...", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38555", "url": "https://ubuntu.com/security/CVE-2025-38555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget : fix use-after-free in composite_dev_cleanup() 1. In func configfs_composite_bind() -> composite_os_desc_req_prepare(): if kmalloc fails, the pointer cdev->os_desc_req will be freed but not set to NULL. Then it will return a failure to the upper-level function. 2. in func configfs_composite_bind() -> composite_dev_cleanup(): it will checks whether cdev->os_desc_req is NULL. If it is not NULL, it will attempt to use it.This will lead to a use-after-free issue. BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0 Read of size 8 at addr 0000004827837a00 by task init/1 CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1 kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c gadget_dev_desc_UDC_store+0x264/0x27c", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2024-36331", "url": "https://ubuntu.com/security/CVE-2024-36331", "cve_description": "Improper initialization of CPU cache memory could allow a privileged attacker with hypervisor access to overwrite SEV-SNP guest memory resulting in loss of data integrity.", "cve_priority": "medium", "cve_public_date": "2025-09-06 18:15:00 UTC" }, { "cve": "CVE-2025-38560", "url": "https://ubuntu.com/security/CVE-2025-38560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sev: Evict cache lines during SNP memory validation An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation. CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed. Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38501", "url": "https://ubuntu.com/security/CVE-2025-38501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: limit repeated connections from clients with the same IP Repeated connections from clients with the same IP address may exhaust the max connections and prevent other normal client connections. This patch limit repeated connections from clients with the same IP.", "cve_priority": "medium", "cve_public_date": "2025-08-16 06:15:00 UTC" }, { "cve": "CVE-2025-38562", "url": "https://ubuntu.com/security/CVE-2025-38562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference error in generate_encryptionkey If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38566", "url": "https://ubuntu.com/security/CVE-2025-38566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix handling of server side tls alerts Scott Mayhew discovered a security exploit in NFS over TLS in tls_alert_recv() due to its assumption it can read data from the msg iterator's kvec.. kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer. This patch proposes to rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38568", "url": "https://ubuntu.com/security/CVE-2025-38568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing TCA_MQPRIO_TC_ENTRY_INDEX is validated using NLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the value TC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stack write in the fp[] array, which only has room for 16 elements (0–15). Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38571", "url": "https://ubuntu.com/security/CVE-2025-38571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix client side handling of tls alerts A security exploit was discovered in NFS over TLS in tls_alert_recv due to its assumption that there is valid data in the msghdr's iterator's kvec. Instead, this patch proposes the rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed control buffer and read in the control message such as a TLS alert. Scott found that a msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38622", "url": "https://ubuntu.com/security/CVE-2025-38622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop UFO packets in udp_rcv_segment() When sending a packet with virtio_net_hdr to tun device, if the gso_type in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr size, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 To trigger gso segment in udp_queue_rcv_skb(), we should also set option UDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcv hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try to pull udphdr, but the skb size has been segmented to gso size, which leads to this crash. Previous commit cf329aa42b66 (\"udp: cope with UDP GRO packet misdirection\") introduces segmentation in UDP receive path only for GRO, which was never intended to be used for UFO, so drop UFO packets in udp_rcv_segment().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38572", "url": "https://ubuntu.com/security/CVE-2025-38572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: reject malicious packets in ipv6_gso_segment() syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header. This 16bit field has a limited range. Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment() WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38574", "url": "https://ubuntu.com/security/CVE-2025-38574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pptp: ensure minimal skb length in pptp_xmit() Commit aabc6596ffb3 (\"net: ppp: Add bound checking for skb data on ppp_sync_txmung\") fixed ppp_sync_txmunge() We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot. BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-39730", "url": "https://ubuntu.com/security/CVE-2025-39730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() The function needs to check the minimal filehandle length before it can access the embedded filehandle.", "cve_priority": "medium", "cve_public_date": "2025-09-07 16:15:00 UTC" }, { "cve": "CVE-2025-38623", "url": "https://ubuntu.com/security/CVE-2025-38623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: pnv_php: Fix surprise plug detection and recovery The existing PowerNV hotplug code did not handle surprise plug events correctly, leading to a complete failure of the hotplug system after device removal and a required reboot to detect new devices. This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot. Issue the appropriate unfreeze and rescan commands on hotplug events, and don't oops on hotplug if pci_bus_to_OF_node() returns NULL. [bhelgaas: tidy comments]", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38576", "url": "https://ubuntu.com/security/CVE-2025-38576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Make EEH driver device hotplug safe Multiple race conditions existed between the PCIe hotplug driver and the EEH driver, leading to a variety of kernel oopses of the same general nature: A second class of oops is also seen when the underlying bus disappears during device recovery. Refactor the EEH module to be PCI rescan and remove safe. Also clean up a few minor formatting / readability issues.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38624", "url": "https://ubuntu.com/security/CVE-2025-38624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: pnv_php: Clean up allocated IRQs on unplug When the root of a nested PCIe bridge configuration is unplugged, the pnv_php driver leaked the allocated IRQ resources for the child bridges' hotplug event notifications, resulting in a panic. Fix this by walking all child buses and deallocating all its IRQ resources before calling pci_hp_remove_devices(). Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so that it is only destroyed in pnv_php_free_slot(), instead of pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will now be called by workers triggered by hot unplug interrupts, so the workqueue needs to stay allocated. The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec [bhelgaas: tidy comments]", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38625", "url": "https://ubuntu.com/security/CVE-2025-38625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pds: Fix missing detach_ioas op When CONFIG_IOMMUFD is enabled and a device is bound to the pds_vfio_pci driver, the following WARN_ON() trace is seen and probe fails: WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio] <...> pds_vfio_pci 0000:08:00.1: probe with driver pds_vfio_pci failed with error -22 This is because the driver's vfio_device_ops.detach_ioas isn't set. Fix this by using the generic vfio_iommufd_physical_detach_ioas function.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38626", "url": "https://ubuntu.com/security/CVE-2025-38626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ \"mode=lfs\" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-39731", "url": "https://ubuntu.com/security/CVE-2025-39731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: vm_unmap_ram() may be called from an invalid context When testing F2FS with xfstests using UFS backed virtual disks the kernel complains sometimes that f2fs_release_decomp_mem() calls vm_unmap_ram() from an invalid context. Example trace from f2fs/007 test: f2fs/007 5s ... [12:59:38][ 8.902525] run fstests f2fs/007 [ 11.468026] BUG: sleeping function called from invalid context at mm/vmalloc.c:2978 [ 11.471849] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 68, name: irq/22-ufshcd [ 11.475357] preempt_count: 1, expected: 0 [ 11.476970] RCU nest depth: 0, expected: 0 [ 11.478531] CPU: 0 UID: 0 PID: 68 Comm: irq/22-ufshcd Tainted: G W 6.16.0-rc5-xfstests-ufs-g40f92e79b0aa #9 PREEMPT(none) [ 11.478535] Tainted: [W]=WARN [ 11.478536] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 11.478537] Call Trace: [ 11.478543] [ 11.478545] dump_stack_lvl+0x4e/0x70 [ 11.478554] __might_resched.cold+0xaf/0xbe [ 11.478557] vm_unmap_ram+0x21/0xb0 [ 11.478560] f2fs_release_decomp_mem+0x59/0x80 [ 11.478563] f2fs_free_dic+0x18/0x1a0 [ 11.478565] f2fs_finish_read_bio+0xd7/0x290 [ 11.478570] blk_update_request+0xec/0x3b0 [ 11.478574] ? sbitmap_queue_clear+0x3b/0x60 [ 11.478576] scsi_end_request+0x27/0x1a0 [ 11.478582] scsi_io_completion+0x40/0x300 [ 11.478583] ufshcd_mcq_poll_cqe_lock+0xa3/0xe0 [ 11.478588] ufshcd_sl_intr+0x194/0x1f0 [ 11.478592] ufshcd_threaded_intr+0x68/0xb0 [ 11.478594] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478599] irq_thread_fn+0x20/0x60 [ 11.478602] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478603] irq_thread+0xb9/0x180 [ 11.478605] ? __pfx_irq_thread_dtor+0x10/0x10 [ 11.478607] ? __pfx_irq_thread+0x10/0x10 [ 11.478609] kthread+0x10a/0x230 [ 11.478614] ? __pfx_kthread+0x10/0x10 [ 11.478615] ret_from_fork+0x7e/0xd0 [ 11.478619] ? __pfx_kthread+0x10/0x10 [ 11.478621] ret_from_fork_asm+0x1a/0x30 [ 11.478623] This patch modifies in_task() check inside f2fs_read_end_io() to also check if interrupts are disabled. This ensures that pages are unmapped asynchronously in an interrupt handler.", "cve_priority": "medium", "cve_public_date": "2025-09-07 16:15:00 UTC" }, { "cve": "CVE-2025-38652", "url": "https://ubuntu.com/security/CVE-2025-38652", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-boundary access in devs.path - touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - truncate -s $((1024*1024*1024)) \\ /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - touch /mnt/f2fs/file - truncate -s $((1024*1024*1024)) /mnt/f2fs/file - mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \\ -c /mnt/f2fs/file - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \\ /mnt/f2fs/loop [16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\\xff\\x01, 511, 0 - 3ffff [16937.192268] F2FS-fs (loop0): Failed to find devices If device path length equals to MAX_PATH_LEN, sbi->devs.path[] may not end up w/ null character due to path array is fully filled, So accidently, fields locate after path[] may be treated as part of device path, result in parsing wrong device path. struct f2fs_dev_info { ... \tchar path[MAX_PATH_LEN]; ... }; Let's add one byte space for sbi->devs.path[] to store null character of device path string.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38577", "url": "https://ubuntu.com/security/CVE-2025-38577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid panic in f2fs_evict_inode As syzbot [1] reported as below: R10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 ---[ end trace 0000000000000000 ]--- ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff88812d962278 by task syz-executor/564 CPU: 1 PID: 564 Comm: syz-executor Tainted: G W 6.1.129-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack+0x21/0x24 lib/dump_stack.c:88 dump_stack_lvl+0xee/0x158 lib/dump_stack.c:106 print_address_description+0x71/0x210 mm/kasan/report.c:316 print_report+0x4a/0x60 mm/kasan/report.c:427 kasan_report+0x122/0x150 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531 f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585 f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703 f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4a0/0xab0 fs/fs-writeback.c:1677 writeback_single_inode+0x221/0x8b0 fs/fs-writeback.c:1733 sync_inode_metadata+0xb6/0x110 fs/fs-writeback.c:2789 f2fs_sync_inode_meta+0x16d/0x2a0 fs/f2fs/checkpoint.c:1159 block_operations fs/f2fs/checkpoint.c:1269 [inline] f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658 kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668 deactivate_locked_super+0x98/0x100 fs/super.c:332 deactivate_super+0xaf/0xe0 fs/super.c:363 cleanup_mnt+0x45f/0x4e0 fs/namespace.c:1186 __cleanup_mnt+0x19/0x20 fs/namespace.c:1193 task_work_run+0x1c6/0x230 kernel/task_work.c:203 exit_task_work include/linux/task_work.h:39 [inline] do_exit+0x9fb/0x2410 kernel/exit.c:871 do_group_exit+0x210/0x2d0 kernel/exit.c:1021 __do_sys_exit_group kernel/exit.c:1032 [inline] __se_sys_exit_group kernel/exit.c:1030 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030 x64_sys_call+0x7b4/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 RIP: 0033:0x7f28b1b8e169 Code: Unable to access opcode bytes at 0x7f28b1b8e13f. RSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 Allocated by task 569: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook+0x4f/0x2c0 mm/slab.h:737 slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3245 [inline] f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419 alloc_inode fs/inode.c:261 [inline] iget_locked+0x186/0x880 fs/inode.c:1373 f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483 f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487 __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690 lookup_slow+0x57/0x70 fs/namei.c:1707 walk_component+0x2e6/0x410 fs/namei ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38578", "url": "https://ubuntu.com/security/CVE-2025-38578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid UAF in f2fs_sync_inode_meta() syzbot reported an UAF issue as below: [1] [2] [1] https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000 ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff888100567dc8 by task kworker/u4:0/8 CPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G W 6.1.129-syzkaller-00017-g642656a36791 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x151/0x1b7 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x158/0x4e0 mm/kasan/report.c:427 kasan_report+0x13c/0x170 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553 f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588 f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706 f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677 writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903 __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974 wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081 wb_check_background_flush fs/fs-writeback.c:2151 [inline] wb_do_writeback fs/fs-writeback.c:2239 [inline] wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266 process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299 worker_thread+0xa60/0x1260 kernel/workqueue.c:2446 kthread+0x26d/0x300 kernel/kthread.c:386 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Allocated by task 298: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333 kasan_slab_alloc include/linux/kasan.h:202 [inline] slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768 slab_alloc_node mm/slub.c:3421 [inline] slab_alloc mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline] kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454 alloc_inode_sb include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline] iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486 f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484 __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689 lookup_slow+0x5a/0x80 fs/namei.c:1706 walk_component+0x2e7/0x410 fs/namei.c:1997 lookup_last fs/namei.c:2454 [inline] path_lookupat+0x16d/0x450 fs/namei.c:2478 filename_lookup+0x251/0x600 fs/namei.c:2507 vfs_statx+0x107/0x4b0 fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat include/linux/fs.h:3434 [inline] __do_sys_newlstat fs/stat.c:423 [inline] __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417 x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by task 0: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516 ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241 __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249 kasan_slab_free include/linux/kasan.h:178 [inline] slab_free_hook mm/slub.c:1745 [inline] slab_free_freelist_hook mm/slub.c:1771 [inline] slab_free mm/slub.c:3686 [inline] kmem_cache_free+0x ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38579", "url": "https://ubuntu.com/security/CVE-2025-38579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix KMSAN uninit-value in extent_info usage KMSAN reported a use of uninitialized value in `__is_extent_mergeable()` and `__is_back_mergeable()` via the read extent tree path. The root cause is that `get_read_extent_info()` only initializes three fields (`fofs`, `blk`, `len`) of `struct extent_info`, leaving the remaining fields uninitialized. This leads to undefined behavior when those fields are accessed later, especially during extent merging. Fix it by zero-initializing the `extent_info` struct before population.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38630", "url": "https://ubuntu.com/security/CVE-2025-38630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref fb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannot allocate a struct fb_modelist. If that happens, the modelist stays empty but the driver continues to register. Add a check for its return value to prevent poteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 (\"fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var\").", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38632", "url": "https://ubuntu.com/security/CVE-2025-38632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinmux: fix race causing mux_owner NULL with active mux_usecount commit 5a3e85c3c397 (\"pinmux: Use sequential access to access desc->pinmux data\") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer. The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux) This sequence leads to a state where the pin appears to be in use (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can cause NULL pointer on next pin_request on the same pin. Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38653", "url": "https://ubuntu.com/security/CVE-2025-38653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. It's a gap in proc_reg_open() after commit 654b33ada4ab(\"proc: fix UAF in proc_get_inode()\"). Followed by AI Viro's suggestion, fix it in same manner.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38581", "url": "https://ubuntu.com/security/CVE-2025-38581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix crash when rebind ccp device for ccp.ko When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38634", "url": "https://ubuntu.com/security/CVE-2025-38634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-charger: Fix null check for power_supply_get_by_name In the cpcap_usb_detect() function, the power_supply_get_by_name() function may return `NULL` instead of an error pointer. To prevent potential null pointer dereferences, Added a null check.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38583", "url": "https://ubuntu.com/security/CVE-2025-38583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: xilinx: vcu: unregister pll_post only if registered correctly If registration of pll_post is failed, it will be set to NULL or ERR, unregistering same will fail with following call trace: Unable to handle kernel NULL pointer dereference at virtual address 008 pc : clk_hw_unregister+0xc/0x20 lr : clk_hw_unregister_fixed_factor+0x18/0x30 sp : ffff800011923850 ... Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu]", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38635", "url": "https://ubuntu.com/security/CVE-2025-38635", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: davinci: Add NULL check in davinci_lpsc_clk_register() devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38587", "url": "https://ubuntu.com/security/CVE-2025-38587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible infinite loop in fib6_info_uses_dev() fib6_info_uses_dev() seems to rely on RCU without an explicit protection. Like the prior fix in rt6_nlmsg_size(), we need to make sure fib6_del_route() or fib6_add_rt2node() have not removed the anchor from the list, or we risk an infinite loop.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38588", "url": "https://ubuntu.com/security/CVE-2025-38588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent infinite loop in rt6_nlmsg_size() While testing prior patch, I was able to trigger an infinite loop in rt6_nlmsg_size() in the following place: list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, \t\t\tfib6_siblings) { \trt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); } This is because fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can confuse rcu readers, because they might no longer see the head of the list. Restart the loop if f6i->fib6_nsiblings is zero.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38590", "url": "https://ubuntu.com/security/CVE-2025-38590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Remove skb secpath if xfrm state is not found Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup. Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0. Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer. This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 ", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38639", "url": "https://ubuntu.com/security/CVE-2025-38639", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_nfacct: don't assume acct name is null-terminated BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721 Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851 [..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523 nfnl_acct_find_get() handles non-null input, but the error printk relied on its presence.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38640", "url": "https://ubuntu.com/security/CVE-2025-38640", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disable migration in nf_hook_run_bpf(). syzbot reported that the netfilter bpf prog can be called without migration disabled in xmit path. Then the assertion in __bpf_prog_run() fails, triggering the splat below. [0] Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf(). [0]: BUG: assuming non migratable context at ./include/linux/filter.h:703 in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session 3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241 CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe7d365d407 Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP:", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38644", "url": "https://ubuntu.com/security/CVE-2025-38644", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reject TDLS operations when station is not associated syzbot triggered a WARN in ieee80211_tdls_oper() by sending NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT, before association completed and without prior TDLS setup. This left internal state like sdata->u.mgd.tdls_peer uninitialized, leading to a WARN_ON() in code paths that assumed it was valid. Reject the operation early if not in station mode or not associated.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38553", "url": "https://ubuntu.com/security/CVE-2025-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Restrict conditions for adding duplicating netems to qdisc tree netem_enqueue's duplication prevention logic breaks when a netem resides in a qdisc tree with other netems - this can lead to a soft lockup and OOM loop in netem_dequeue, as seen in [1]. Ensure that a duplicating netem cannot exist in a tree with other netems. Previous approaches suggested in discussions in chronological order: 1) Track duplication status or ttl in the sk_buff struct. Considered too specific a use case to extend such a struct, though this would be a resilient fix and address other previous and potential future DOS bugs like the one described in loopy fun [2]. 2) Restrict netem_enqueue recursion depth like in act_mirred with a per cpu variable. However, netem_dequeue can call enqueue on its child, and the depth restriction could be bypassed if the child is a netem. 3) Use the same approach as in 2, but add metadata in netem_skb_cb to handle the netem_dequeue case and track a packet's involvement in duplication. This is an overly complex approach, and Jamal notes that the skb cb can be overwritten to circumvent this safeguard. 4) Prevent the addition of a netem to a qdisc tree if its ancestral path contains a netem. However, filters and actions can cause a packet to change paths when re-enqueued to the root from netem duplication, leading us to the current solution: prevent a duplicating netem from inhabiting the same tree as other netems. [1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/ [2] https://lwn.net/Articles/719297/", "cve_priority": "medium", "cve_public_date": "2025-08-19 06:15:00 UTC" }, { "cve": "CVE-2025-38645", "url": "https://ubuntu.com/security/CVE-2025-38645", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Check device memory pointer before usage Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5_init_once() fails.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38601", "url": "https://ubuntu.com/security/CVE-2025-38601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: clear initialized flag for deinit-ed srng lists In a number of cases we see kernel panics on resume due to ath11k kernel page fault, which happens under the following circumstances: 1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..] 2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag. 3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170 Clear per-list ->initialized flag in ath11k_hal_srng_deinit().", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38602", "url": "https://ubuntu.com/security/CVE-2025-38602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iwlwifi: Add missing check for alloc_ordered_workqueue Add check for the return value of alloc_ordered_workqueue since it may return NULL pointer.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38604", "url": "https://ubuntu.com/security/CVE-2025-38604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Kill URBs before clearing tx status queue In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing b_tx_status.queue. This change prevents callbacks from using already freed skb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Tested on RTL8187BvE device. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38646", "url": "https://ubuntu.com/security/CVE-2025-38646", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band With a quite rare chance, RX report might be problematic to make SW think a packet is received on 6 GHz band even if the chip does not support 6 GHz band actually. Since SW won't initialize stuffs for unsupported bands, NULL dereference will happen then in the sequence, rtw89_vif_rx_stats_iter() -> rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it. The following is a crash log for this case. BUG: kernel NULL pointer dereference, address: 0000000000000032 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G U 6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4) Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024 RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core] Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 <41> 33 45 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85 RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246 RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011 RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6 RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000 R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4 R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)] __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)] rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)] rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)]", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38608", "url": "https://ubuntu.com/security/CVE-2025-38608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls When sending plaintext data, we initially calculated the corresponding ciphertext length. However, if we later reduced the plaintext data length via socket policy, we failed to recalculate the ciphertext length. This results in transmitting buffers containing uninitialized data during ciphertext transmission. This causes uninitialized bytes to be appended after a complete \"Application Data\" packet, leading to errors on the receiving end when parsing TLS record.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38609", "url": "https://ubuntu.com/security/CVE-2025-38609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Check governor before using governor->name Commit 96ffcdf239de (\"PM / devfreq: Remove redundant governor_name from struct devfreq\") removes governor_name and uses governor->name to replace it. But devfreq->governor may be NULL and directly using devfreq->governor->name may cause null pointer exception. Move the check of governor to before using governor->name.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38610", "url": "https://ubuntu.com/security/CVE-2025-38610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() The get_pd_power_uw() function can crash with a NULL pointer dereference when em_cpu_get() returns NULL. This occurs when a CPU becomes impossible during runtime, causing get_cpu_device() to return NULL, which propagates through em_cpu_get() and leads to a crash when em_span_cpus() dereferences the NULL pointer. Add a NULL check after em_cpu_get() and return 0 if unavailable, matching the existing fallback behavior in __dtpm_cpu_setup(). [ rjw: Drop an excess empty code line ]", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38612", "url": "https://ubuntu.com/security/CVE-2025-38612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() In the error paths after fb_info structure is successfully allocated, the memory allocated in fb_deferred_io_init() for info->pagerefs is not freed. Fix that by adding the cleanup function on the error path.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38648", "url": "https://ubuntu.com/security/CVE-2025-38648", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: stm32: Check for cfg availability in stm32_spi_probe The stm32_spi_probe function now includes a check to ensure that the pointer returned by of_device_get_match_data is not NULL before accessing its members. This resolves a warning where a potential NULL pointer dereference could occur when accessing cfg->has_device_mode. Before accessing the 'has_device_mode' member, we verify that 'cfg' is not NULL. If 'cfg' is NULL, an error message is logged. This change ensures that the driver does not attempt to access configuration data if it is not available, thus preventing a potential system crash due to a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38659", "url": "https://ubuntu.com/security/CVE-2025-38659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: No more self recovery When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-39734", "url": "https://ubuntu.com/security/CVE-2025-39734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"fs/ntfs3: Replace inode_trylock with inode_lock\" This reverts commit 69505fe98f198ee813898cbcaf6770949636430b. Initially, conditional lock acquisition was removed to fix an xfstest bug that was observed during internal testing. The deadlock reported by syzbot is resolved by reintroducing conditional acquisition. The xfstest bug no longer occurs on kernel version 6.16-rc1 during internal testing. I assume that changes in other modules may have contributed to this.", "cve_priority": "medium", "cve_public_date": "2025-09-07 16:15:00 UTC" }, { "cve": "CVE-2025-38650", "url": "https://ubuntu.com/security/CVE-2025-38650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: remove mutex_lock check in hfsplus_free_extents Syzbot reported an issue in hfsplus filesystem: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 \thfsplus_free_extents+0x700/0xad0 Call Trace: hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606 hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56 cont_expand_zero fs/buffer.c:2383 [inline] cont_write_begin+0x2cf/0x860 fs/buffer.c:2446 hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52 generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347 hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263 notify_change+0xe38/0x10f0 fs/attr.c:420 do_truncate+0x1fb/0x2e0 fs/open.c:65 do_sys_ftruncate+0x2eb/0x380 fs/open.c:193 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd To avoid deadlock, Commit 31651c607151 (\"hfsplus: avoid deadlock on file truncation\") unlock extree before hfsplus_free_extents(), and add check wheather extree is locked in hfsplus_free_extents(). However, when operations such as hfsplus_file_release, hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed concurrently in different files, it is very likely to trigger the WARN_ON, which will lead syzbot and xfstest to consider it as an abnormality. The comment above this warning also describes one of the easy triggering situations, which can easily trigger and cause xfstest&syzbot to report errors. [task A]\t\t\t[task B] ->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock \t\t\t\t->hfsplus_write_begin \t\t\t\t ->hfsplus_get_block \t\t\t\t ->hfsplus_file_extend \t\t\t\t ->hfsplus_ext_read_extent \t\t\t\t ->hfs_find_init \t\t\t\t\t ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!! Several threads could try to lock the shared extents tree. And warning can be triggered in one thread when another thread has locked the tree. This is the wrong behavior of the code and we need to remove the warning.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38615", "url": "https://ubuntu.com/security/CVE-2025-38615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's \"icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier\". In some it's outright \"we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles\".", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38351", "url": "https://ubuntu.com/security/CVE-2025-38351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated. However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error(): invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm] Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms \"real\" Hyper-V interprets the specification in the same way. Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out \"bad\" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.", "cve_priority": "medium", "cve_public_date": "2025-07-19 12:15:00 UTC" }, { "cve": "CVE-2025-38675", "url": "https://ubuntu.com/security/CVE-2025-38675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: state: initialize state_ptrs earlier in xfrm_state_find In case of preemption, xfrm_state_look_at will find a different pcpu_id and look up states for that other CPU. If we matched a state for CPU2 in the state_cache while the lookup started on CPU1, we will jump to \"found\", but the \"best\" state that we got will be ignored and we will enter the \"acquire\" block. This block uses state_ptrs, which isn't initialized at this point. Let's initialize state_ptrs just after taking rcu_read_lock. This will also prevent a possible misuse in the future, if someone adjusts this function.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38322", "url": "https://ubuntu.com/security/CVE-2025-38322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix crash in icl_update_topdown_event() The perf_fuzzer found a hard-lockup crash on a RaptorLake machine: Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision 9660/0VJ762 RIP: 0010:native_read_pmc+0x7/0x40 Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Call Trace: icl_update_topdown_event+0x165/0x190 ? ktime_get+0x38/0xd0 intel_pmu_read_event+0xf9/0x210 __perf_event_read+0xf9/0x210 CPUs 16-23 are E-core CPUs that don't support the perf metrics feature. The icl_update_topdown_event() should not be invoked on these CPUs. It's a regression of commit: f9bdf1f95339 (\"perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read\") The bug introduced by that commit is that the is_topdown_event() function is mistakenly used to replace the is_topdown_count() call to check if the topdown functions for the perf metrics feature should be invoked. Fix it.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-37777", "url": "https://ubuntu.com/security/CVE-2025-37777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __smb2_lease_break_noti() Move tcp_transport free to ksmbd_conn_free. If ksmbd connection is referenced when ksmbd server thread terminates, It will not be freed, but conn->tcp_transport is freed. __smb2_lease_break_noti can be performed asynchronously when the connection is disconnected. __smb2_lease_break_noti calls ksmbd_conn_write, which can cause use-after-free when conn->ksmbd_transport is already freed.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37925", "url": "https://ubuntu.com/security/CVE-2025-37925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: reject on-disk inodes of an unsupported type Syzbot has reported the following BUG: kernel BUG at fs/inode.c:668! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clear_inode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This happens when 'clear_inode()' makes an attempt to finalize an underlying JFS inode of unknown type. According to JFS layout description from https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to 15 are reserved for future extensions and should not be encountered on a valid filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-38663", "url": "https://ubuntu.com/security/CVE-2025-38663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid file types when reading inodes To prevent inodes with invalid file types from tripping through the vfs and causing malfunctions or assertion failures, add a missing sanity check when reading an inode from a block device. If the file type is not valid, treat it as a filesystem error.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38664", "url": "https://ubuntu.com/security/CVE-2025-38664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix a null pointer dereference in ice_copy_and_init_pkg() Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38670", "url": "https://ubuntu.com/security/CVE-2025-38670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks. In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SP_EL0), clobbering it. In `call_on_irq_stack()`, it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls `call_on_irq_stack()` and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use ! This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK or FPAC if enabled. This is possible on a default config, but unlikely. However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very* frequently depending on the system configuration and workload, leading to unpredictable kernel panics. Completely mask DAIF in `cpu_switch_to()` and restore it when returning. Do the same in `call_on_irq_stack()`, but restore and mask around the branch. Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency of behaviour between all configurations. Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38671", "url": "https://ubuntu.com/security/CVE-2025-38671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qup: jump out of the loop in case of timeout Original logic only sets the return value but doesn't jump out of the loop if the bus is kept active by a client. This is not expected. A malicious or buggy i2c client can hang the kernel in this case and should be avoided. This is observed during a long time test with a PCA953x GPIO extender. Fix it by changing the logic to not only sets the return value, but also jumps out of the loop and return to the caller with -ETIMEDOUT.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-39726", "url": "https://ubuntu.com/security/CVE-2025-39726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-38665", "url": "https://ubuntu.com/security/CVE-2025-38665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode Andrei Lalaev reported a NULL pointer deref when a CAN device is restarted from Bus Off and the driver does not implement the struct can_priv::do_set_mode callback. There are 2 code path that call struct can_priv::do_set_mode: - directly by a manual restart from the user space, via can_changelink() - delayed automatic restart after bus off (deactivated by default) To prevent the NULL pointer deference, refuse a manual restart or configure the automatic restart delay in can_changelink() and report the error via extack to user space. As an additional safety measure let can_restart() return an error if can_priv::do_set_mode is not set instead of dereferencing it unchecked.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38668", "url": "https://ubuntu.com/security/CVE-2025-38668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix NULL dereference on unbind due to stale coupling data Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind. This can happen during runtime PM or other regulator operations that rely on coupling metadata. For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state. Ensure n_coupled is set to 0 to prevent access to invalid pointers.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38335", "url": "https://ubuntu.com/security/CVE-2025-38335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context, but the input_event() takes a spin_lock, which isn't allowed there as it is converted to a rt_spin_lock(). [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context. Relax the hrtimer not to use the hard context.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-22115", "url": "https://ubuntu.com/security/CVE-2025-22115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix block group refcount race in btrfs_create_pending_block_groups() Block group creation is done in two phases, which results in a slightly unintuitive property: a block group can be allocated/deallocated from after btrfs_make_block_group() adds it to the space_info with btrfs_add_bg_to_space_info(), but before creation is completely completed in btrfs_create_pending_block_groups(). As a result, it is possible for a block group to go unused and have 'btrfs_mark_bg_unused' called on it concurrently with 'btrfs_create_pending_block_groups'. This causes a number of issues, which were fixed with the block group flag 'BLOCK_GROUP_FLAG_NEW'. However, this fix is not quite complete. Since it does not use the unused_bg_lock, it is possible for the following race to occur: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail And we get into the exact same broken ref count and invalid new_bgs state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to prevent. The broken refcount aspect will result in a warning like: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] [1272.961238] ---[ end trace 0000000000000000 ]--- Though we have seen them in the async discard workfn as well. It is most likely to happen after a relocation finishes which cancels discard, tears down the block group, etc. Fix this fully by taking the lock arou ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38549", "url": "https://ubuntu.com/security/CVE-2025-38549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths When processing mount options, efivarfs allocates efivarfs_fs_info (sfi) early in fs_context initialization. However, sfi is associated with the superblock and typically freed when the superblock is destroyed. If the fs_context is released (final put) before fill_super is called—such as on error paths or during reconfiguration—the sfi structure would leak, as ownership never transfers to the superblock. Implement the .free callback in efivarfs_context_ops to ensure any allocated sfi is properly freed if the fs_context is torn down before fill_super, preventing this memory leak.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38551", "url": "https://ubuntu.com/security/CVE-2025-38551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix recursived rtnl_lock() during probe() The deadlock appears in a stack trace like: virtnet_probe() rtnl_lock() virtio_config_changed_work() netdev_notify_peers() rtnl_lock() It happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the virtio-net driver is still probing. The config_work in probe() will get scheduled until virtnet_open() enables the config change notification via virtio_config_driver_enable().", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38531", "url": "https://ubuntu.com/security/CVE-2025-38531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: common: st_sensors: Fix use of uninitialize device structs Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device. This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well. The issue is reported and traced here: [1]", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38552", "url": "https://ubuntu.com/security/CVE-2025-38552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: plug races between subflow fail and subflow creation We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger. The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock. The socket fallback makes such flag true, and also receiving or sending an MP_FAIL option. The field 'allow_infinite_fallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38491", "url": "https://ubuntu.com/security/CVE-2025-38491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: make fallback action and fallback decision atomic Syzkaller reported the following splat: WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline] RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432 tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975 tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166 tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline] ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644 handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90 kernel/softirq.c:480 __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33 [inline] inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524 mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcp_check_listen_stop net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435 inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70 fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xd4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38469", "url": "https://ubuntu.com/security/CVE-2025-38469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll hypercalls kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host for more than one event channel potr (nr_ports > 1). After the kmalloc_array(), the error paths need to go through the \"out\" label, but the call to kvm_read_guest_virt() does not. [Adjusted commit message. - Paolo]", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38499", "url": "https://ubuntu.com/security/CVE-2025-38499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. \"Wouldn't be able to undo\" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above.", "cve_priority": "medium", "cve_public_date": "2025-08-11 16:15:00 UTC" }, { "cve": "CVE-2025-38524", "url": "https://ubuntu.com/security/CVE-2025-38524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recv-recv race of completed call If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again. In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be \"released\", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly: \tkernel BUG at net/rxrpc/recvmsg.c:474! Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38468", "url": "https://ubuntu.com/security/CVE-2025-38468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree htb_lookup_leaf has a BUG_ON that can trigger with the following: tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 htb rate 64bit tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2:1 handle 3: blackhole ping -I lo -c1 -W0.001 127.0.0.1 The root cause is the following: 1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc 2. netem_dequeue calls enqueue on the child qdisc 3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase 5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ON The function graph for this scenario is shown here: 0) | htb_enqueue() { 0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() { 0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() { 0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() { 0) | qdisc_lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() { 0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() { 0) | BUG_ON(); ------------------------------------------ The full original bug report can be seen here [1]. We can fix this just by returning NULL instead of the BUG_ON, as htb_dequeue_tree returns NULL when htb_lookup_leaf returns NULL. [1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38470", "url": "https://ubuntu.com/security/CVE-2025-38470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime Assuming the \"rx-vlan-filter\" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme. The first problem is a memory leak that can happen if the \"rx-vlan-filter\" feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1 When the device is put administratively down the \"rx-vlan-filter\" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1]. Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the \"rx-vlan-filter\" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime: $ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0 Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the \"rx-vlan-filter\" feature. [1] unreferenced object 0xffff8880068e3100 (size 256): comm \"ip\", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 [2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: stm.full_len\").", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38472", "url": "https://ubuntu.com/security/CVE-2025-38472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: fix crash due to removal of uninitialised entry A crash in conntrack was reported while trying to unlink the conntrack entry from the hash bucket list: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..] The nf_conn struct is marked as allocated from slab but appears to be in a partially initialised state: ct hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected. Everything else looks like normal udp conntrack entry. If we ignore ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value. If it were not for the presence of IPS_CONFIRMED, __nf_conntrack_find_get() would have skipped the entry. Theory is that we did hit following race: cpu x \t\t\tcpu y\t\t\tcpu z found entry E\t\tfound entry E E is expired\t\t nf_ct_delete() return E to rcu slab \t\t\t\t\tinit_conntrack \t\t\t\t\tE is re-inited, \t\t\t\t\tct->status set to 0 \t\t\t\t\treply tuplehash hnnode.pprev \t\t\t\t\tstores hash value. cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y was preempted before checking for expiry and/or confirm bit. \t\t\t\t\t->refcnt set to 1 \t\t\t\t\tE now owned by skb \t\t\t\t\t->timeout set to 30000 If cpu y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit. \t\t\t\t\tnf_conntrack_confirm gets called \t\t\t\t\tsets: ct->status |= CONFIRMED \t\t\t\t\tThis is wrong: E is not yet added \t\t\t\t\tto hashtable. cpu y resumes, it observes E as expired but CONFIRMED: \t\t\t \t\t\tnf_ct_expired() \t\t\t -> yes (ct->timeout is 30s) \t\t\tconfirmed bit set. cpu y will try to delete E from the hashtable: \t\t\tnf_ct_delete() -> set DYING bit \t\t\t__nf_ct_delete_from_lists Even this scenario doesn't guarantee a crash: cpu z still holds the table bucket lock(s) so y blocks: \t\t\twait for spinlock held by z \t\t\t\t\tCONFIRMED is set but there is no \t\t\t\t\tguarantee ct will be added to hash: \t\t\t\t\t\"chaintoolong\" or \"clash resolution\" \t\t\t\t\tlogic both skip the insert step. \t\t\t\t\treply hnnode.pprev still stores the \t\t\t\t\thash value. \t\t\t\t\tunlocks spinlock \t\t\t\t\treturn NF_DROP \t\t\t In case CPU z does insert the entry into the hashtable, cpu y will unlink E again right away but no crash occurs. Without 'cpu y' race, 'garbage' hlist is of no consequence: ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy. To resolve this, move the IPS_CONFIRMED assignment after the table insertion but before the unlock. Pablo points out that the confirm-bit-store could be reordered to happen before hlist add resp. the timeout fixup, so switch to set_bit and before_atomic memory barrier to prevent this. It doesn't matter if other CPUs can observe a newly inserted entry right before the CONFIRMED bit was set: Such event cannot be distinguished from above \"E is the old incarnation\" case: the entry will be skipped. Also change nf_ct_should_gc() to first check the confirmed bit. The gc sequence is: 1. Check if entry has expired, if not skip to next entry 2. Obtain a reference to the expired entry. 3. Call nf_ct_should_gc() to double-check step 1. nf_ct_should_gc() is thus called only for entries that already failed an expiry check. After this patch, once the confirmed bit check pas ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38550", "url": "https://ubuntu.com/security/CVE-2025-38550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Delay put pmc->idev in mld_del_delrec() pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec() does, the reference should be put after ip6_mc_clear_src() return.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38473", "url": "https://ubuntu.com/security/CVE-2025-38473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0] l2cap_sock_resume_cb() has a similar problem that was fixed by commit 1bff51ea59a9 (\"Bluetooth: fix use-after-free error in lock_sock_nested()\"). Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed under l2cap_sock_resume_cb(), we can avoid the issue simply by checking if chan->data is NULL. Let's not access to the killed socket in l2cap_sock_resume_cb(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: hci0 hci_rx_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38474", "url": "https://ubuntu.com/security/CVE-2025-38474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: net: sierra: check for no status endpoint The driver checks for having three endpoints and having bulk in and out endpoints, but not that the third endpoint is interrupt input. Rectify the omission.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38526", "url": "https://ubuntu.com/security/CVE-2025-38526", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: add NULL check in eswitch lag check The function ice_lag_is_switchdev_running() is being called from outside of the LAG event handler code. This results in the lag->upper_netdev being NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a check before it is dereferenced.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38548", "url": "https://ubuntu.com/security/CVE-2025-38548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Validate the size of the received input buffer Add buffer_recv_size to store the size of the received bytes. Validate buffer_recv_size in send_usb_cmd().", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38537", "url": "https://ubuntu.com/security/CVE-2025-38537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Don't register LEDs for genphy If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an \"leds\" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38527", "url": "https://ubuntu.com/security/CVE-2025-38527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in cifs_oplock_break A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free. Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38476", "url": "https://ubuntu.com/security/CVE-2025-38476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpl: Fix use-after-free in rpl_do_srh_inline(). Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers the splat below [0]. rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after skb_cow_head(), which is illegal as the header could be freed then. Let's fix it by making oldhdr to a local struct instead of a pointer. [0]: [root@fedora net]# ./lwt_dst_cache_ref_loop.sh ... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543 CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2)) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 Allocated by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1)) ip6_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38528", "url": "https://ubuntu.com/security/CVE-2025-38528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject %p% format string in bprintf-like helpers static const char fmt[] = \"%p%\"; bpf_trace_printk(fmt, sizeof(fmt)); The above BPF program isn't rejected and causes a kernel warning at runtime: Please remove unsupported %\\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0 This happens because bpf_bprintf_prepare skips over the second %, detected as punctuation, while processing %p. This patch fixes it by not skipping over punctuation. %\\x00 is then processed in the next iteration and rejected.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38478", "url": "https://ubuntu.com/security/CVE-2025-38478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Fix initialization of data for instructions that write to subdevice Some Comedi subdevice instruction handlers are known to access instruction data elements beyond the first `insn->n` elements in some cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions allocate at least `MIN_SAMPLES` (16) data elements to deal with this, but they do not initialize all of that. For Comedi instruction codes that write to the subdevice, the first `insn->n` data elements are copied from user-space, but the remaining elements are left uninitialized. That could be a problem if the subdevice instruction handler reads the uninitialized data. Ensure that the first `MIN_SAMPLES` elements are initialized before calling these instruction handlers, filling the uncopied elements with 0. For `do_insnlist_ioctl()`, the same data buffer elements are used for handling a list of instructions, so ensure the first `MIN_SAMPLES` elements are initialized for each instruction that writes to the subdevice.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38480", "url": "https://ubuntu.com/security/CVE-2025-38480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Fix use of uninitialized data in insn_rw_emulate_bits() For Comedi `INSN_READ` and `INSN_WRITE` instructions on \"digital\" subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and `COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have `insn_read` and `insn_write` handler functions, but to have an `insn_bits` handler function for handling Comedi `INSN_BITS` instructions. In that case, the subdevice's `insn_read` and/or `insn_write` function handler pointers are set to point to the `insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`. For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the supplied `data[0]` value is a valid copy from user memory. It will at least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in \"comedi_fops.c\" ensure at lease `MIN_SAMPLES` (16) elements are allocated. However, if `insn->n` is 0 (which is allowable for `INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain uninitialized data, and certainly contains invalid data, possibly from a different instruction in the array of instructions handled by `do_insnlist_ioctl()`. This will result in an incorrect value being written to the digital output channel (or to the digital input/output channel if configured as an output), and may be reflected in the internal saved state of the channel. Fix it by returning 0 early if `insn->n` is 0, before reaching the code that accesses `data[0]`. Previously, the function always returned 1 on success, but it is supposed to be the number of data samples actually read or written up to `insn->n`, which is 0 in this case.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38481", "url": "https://ubuntu.com/security/CVE-2025-38481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to hold the array of `struct comedi_insn`, getting the length from the `n_insns` member of the `struct comedi_insnlist` supplied by the user. The allocation will fail with a WARNING and a stack dump if it is too large. Avoid that by failing with an `-EINVAL` error if the supplied `n_insns` value is unreasonable. Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Set this to the same value as `MAX_SAMPLES` (65536), which is the maximum allowed sum of the values of the member `n` in the array of `struct comedi_insn`, and sensible comedi instructions will have an `n` of at least 1.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38482", "url": "https://ubuntu.com/security/CVE-2025-38482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: das6402: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: \t/* IRQs 2,3,5,6,7, 10,11,15 are valid for \"enhanced\" mode */ \tif ((1 << it->options[1]) & 0x8cec) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38483", "url": "https://ubuntu.com/security/CVE-2025-38483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: das16m1: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: \t/* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ \tif ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38529", "url": "https://ubuntu.com/security/CVE-2025-38529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: aio_iiro_16: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: \tif ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38530", "url": "https://ubuntu.com/security/CVE-2025-38530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: pcl812: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: \tif ((1 << it->options[1]) & board->irq_bits) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38485", "url": "https://ubuntu.com/security/CVE-2025-38485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with iio_for_each_active_channel()) without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode in the middle of the interrupt that flushes the fifo. Fix this by calling synchronize_irq() to ensure that no interrupt is currently running when disabling buffer mode. Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [...] _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290 fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178 fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c irq_thread_fn from irq_thread+0x110/0x1f4 irq_thread from kthread+0xe0/0xfc kthread from ret_from_fork+0x14/0x2c", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38487", "url": "https://ubuntu.com/security/CVE-2025-38487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled Mitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ...", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2024-50047", "url": "https://ubuntu.com/security/CVE-2024-50047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Call Trace: [ 194.200191] [ 194.200327] dump_stack_lvl+0x4e/0x70 [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110 [ 194.200809] print_report+0x174/0x505 [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 194.201352] ? srso_return_thunk+0x5/0x5f [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0 [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()). Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it's always going to be a synchronous operation.", "cve_priority": "high", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2025-38488", "url": "https://ubuntu.com/security/CVE-2025-38488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in crypt_message when using async crypto The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...); Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory. This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences. The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected. Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for async completion notification - crypto_wait_req() to wait for operation completion This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38489", "url": "https://ubuntu.com/security/CVE-2025-38489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again Commit 7ded842b356d (\"s390/bpf: Fix bpf_plt pointer arithmetic\") has accidentally removed the critical piece of commit c730fce7c70c (\"s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL\"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear. Restore the fix and add a comment.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38532", "url": "https://ubuntu.com/security/CVE-2025-38532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: properly reset Rx ring descriptor When device reset is triggered by feature changes such as toggling Rx VLAN offload, wx->do_reset() is called to reinitialize Rx rings. The hardware descriptor ring may retain stale values from previous sessions. And only set the length to 0 in rx_desc[0] would result in building malformed SKBs. Fix it to ensure a clean slate after device reset. [ 549.186435] [ C16] ------------[ cut here ]------------ [ 549.186457] [ C16] kernel BUG at net/core/skbuff.c:2814! [ 549.186468] [ C16] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 549.186472] [ C16] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Kdump: loaded Not tainted 6.16.0-rc4+ #23 PREEMPT(voluntary) [ 549.186476] [ C16] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 549.186478] [ C16] RIP: 0010:__pskb_pull_tail+0x3ff/0x510 [ 549.186484] [ C16] Code: 06 f0 ff 4f 34 74 7b 4d 8b 8c 24 c8 00 00 00 45 8b 84 24 c0 00 00 00 e9 c8 fd ff ff 48 c7 44 24 08 00 00 00 00 e9 5e fe ff ff <0f> 0b 31 c0 e9 23 90 5b ff 41 f7 c6 ff 0f 00 00 75 bf 49 8b 06 a8 [ 549.186487] [ C16] RSP: 0018:ffffb391c0640d70 EFLAGS: 00010282 [ 549.186490] [ C16] RAX: 00000000fffffff2 RBX: ffff8fe7e4d40200 RCX: 00000000fffffff2 [ 549.186492] [ C16] RDX: ffff8fe7c3a4bf8e RSI: 0000000000000180 RDI: ffff8fe7c3a4bf40 [ 549.186494] [ C16] RBP: ffffb391c0640da8 R08: ffff8fe7c3a4c0c0 R09: 000000000000000e [ 549.186496] [ C16] R10: ffffb391c0640d88 R11: 000000000000000e R12: ffff8fe7e4d40200 [ 549.186497] [ C16] R13: 00000000fffffff2 R14: ffff8fe7fa01a000 R15: 00000000fffffff2 [ 549.186499] [ C16] FS: 0000000000000000(0000) GS:ffff8fef5ae40000(0000) knlGS:0000000000000000 [ 549.186502] [ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 549.186503] [ C16] CR2: 00007f77d81d6000 CR3: 000000051a032000 CR4: 0000000000750ef0 [ 549.186505] [ C16] PKRU: 55555554 [ 549.186507] [ C16] Call Trace: [ 549.186510] [ C16] [ 549.186513] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186517] [ C16] __skb_pad+0xc7/0xf0 [ 549.186523] [ C16] wx_clean_rx_irq+0x355/0x3b0 [libwx] [ 549.186533] [ C16] wx_poll+0x92/0x120 [libwx] [ 549.186540] [ C16] __napi_poll+0x28/0x190 [ 549.186544] [ C16] net_rx_action+0x301/0x3f0 [ 549.186548] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186551] [ C16] ? __raw_spin_lock_irqsave+0x1e/0x50 [ 549.186554] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186557] [ C16] ? wake_up_nohz_cpu+0x35/0x160 [ 549.186559] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186563] [ C16] handle_softirqs+0xf9/0x2c0 [ 549.186568] [ C16] __irq_exit_rcu+0xc7/0x130 [ 549.186572] [ C16] common_interrupt+0xb8/0xd0 [ 549.186576] [ C16] [ 549.186577] [ C16] [ 549.186579] [ C16] asm_common_interrupt+0x22/0x40 [ 549.186582] [ C16] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 549.186585] [ C16] Code: 00 00 e8 11 0e 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 0d ed 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 549.186587] [ C16] RSP: 0018:ffffb391c0277e78 EFLAGS: 00000246 [ 549.186590] [ C16] RAX: ffff8fef5ae40000 RBX: 0000000000000003 RCX: 0000000000000000 [ 549.186591] [ C16] RDX: 0000007fde0faac5 RSI: ffffffff826e53f6 RDI: ffffffff826fa9b3 [ 549.186593] [ C16] RBP: ffff8fe7c3a20800 R08: 0000000000000002 R09: 0000000000000000 [ 549.186595] [ C16] R10: 0000000000000000 R11: 000000000000ffff R12: ffffffff82ed7a40 [ 549.186596] [ C16] R13: 0000007fde0faac5 R14: 0000000000000003 R15: 0000000000000000 [ 549.186601] [ C16] ? cpuidle_enter_state+0xb3/0x420 [ 549.186605] [ C16] cpuidle_en ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38533", "url": "https://ubuntu.com/security/CVE-2025-38533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix the using of Rx buffer DMA The wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Althrough such error has not yet occurred, it is worth fixing in the code.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38490", "url": "https://ubuntu.com/security/CVE-2025-38490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: remove duplicate page_pool_put_full_page() page_pool_put_full_page() should only be invoked when freeing Rx buffers or building a skb if the size is too short. At other times, the pages need to be reused. So remove the redundant page put. In the original code, double free pages cause kernel panic: [ 876.949834] __irq_exit_rcu+0xc7/0x130 [ 876.949836] common_interrupt+0xb8/0xd0 [ 876.949838] [ 876.949838] [ 876.949840] asm_common_interrupt+0x22/0x40 [ 876.949841] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246 [ 876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000 [ 876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e [ 876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed [ 876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580 [ 876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000 [ 876.949852] ? cpuidle_enter_state+0xb3/0x420 [ 876.949855] cpuidle_enter+0x29/0x40 [ 876.949857] cpuidle_idle_call+0xfd/0x170 [ 876.949859] do_idle+0x7a/0xc0 [ 876.949861] cpu_startup_entry+0x25/0x30 [ 876.949862] start_secondary+0x117/0x140 [ 876.949864] common_startup_64+0x13e/0x148 [ 876.949867] [ 876.949868] ---[ end trace 0000000000000000 ]--- [ 876.949869] ------------[ cut here ]------------ [ 876.949870] list_del corruption, ffffead40445a348->next is NULL [ 876.949873] WARNING: CPU: 14 PID: 0 at lib/list_debug.c:52 __list_del_entry_valid_or_report+0x67/0x120 [ 876.949875] Modules linked in: snd_hrtimer(E) bnep(E) binfmt_misc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amd_atl(E) snd_hda_codec_realtek(E) intel_rapl_msr(E) snd_hda_codec_generic(E) intel_rapl_common(E) snd_hda_scodec_component(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) edac_mce_amd(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) amdxcp(E) kvm_amd(E) snd_hwdep(E) gpu_sched(E) drm_panel_backlight_quirks(E) cec(E) snd_pcm(E) drm_buddy(E) snd_seq_dummy(E) drm_ttm_helper(E) btusb(E) kvm(E) snd_seq_oss(E) btrtl(E) ttm(E) btintel(E) snd_seq_midi(E) btbcm(E) drm_exec(E) snd_seq_midi_event(E) i2c_algo_bit(E) snd_rawmidi(E) bluetooth(E) drm_suballoc_helper(E) irqbypass(E) snd_seq(E) ghash_clmulni_intel(E) sha512_ssse3(E) drm_display_helper(E) aesni_intel(E) snd_seq_device(E) rfkill(E) snd_timer(E) gf128mul(E) drm_client_lib(E) drm_kms_helper(E) snd(E) i2c_piix4(E) joydev(E) soundcore(E) wmi_bmof(E) ccp(E) k10temp(E) i2c_smbus(E) gpio_amdpt(E) i2c_designware_platform(E) gpio_generic(E) sg(E) [ 876.949914] i2c_designware_core(E) sch_fq_codel(E) parport_pc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) ip_tables(E) ext4 crc16 mbcache jbd2 sd_mod sfp mdio_i2c i2c_core txgbe ahci ngbe pcs_xpcs libahci libwx r8169 phylink libata realtek ptp pps_core video wmi [ 876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G W E 6.16.0-rc2+ #20 PREEMPT(voluntary) [ 876.949935] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE [ 876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 876.949936] RIP: 0010:__list_del_entry_valid_or_report+0x67/0x120 [ 876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff <0f> 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8 [ 876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282 [ 876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000 [ 876.949942] RDX: 0000000000000105 RSI: 00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38538", "url": "https://ubuntu.com/security/CVE-2025-38538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: nbpfaxi: Fix memory corruption in probe() The nbpf->chan[] array is allocated earlier in the nbpf_probe() function and it has \"num_channels\" elements. These three loops iterate one element farther than they should and corrupt memory. The changes to the second loop are more involved. In this case, we're copying data from the irqbuf[] array into the nbpf->chan[] array. If the data in irqbuf[i] is the error IRQ then we skip it, so the iterators are not in sync. I added a check to ensure that we don't go beyond the end of the irqbuf[] array. I'm pretty sure this can't happen, but it seemed harmless to add a check. On the other hand, after the loop has ended there is a check to ensure that the \"chan\" iterator is where we expect it to be. In the original code we went one element beyond the end of the array so the iterator wasn't in the correct place and it would always return -EINVAL. However, now it will always be in the correct place. I deleted the check since we know the result.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38493", "url": "https://ubuntu.com/security/CVE-2025-38493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/osnoise: Fix crash in timerlat_dump_stack() We have observed kernel panics when using timerlat with stack saving, with the following dmesg output: memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() constructs the ftrace stack entry like this: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; Since commit e7186af7fb26 (\"tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure\"), struct stack_entry marks its caller field with __counted_by(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow. Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to __ftrace_trace_stack().", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38539", "url": "https://ubuntu.com/security/CVE-2025-38539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Add down_write(trace_event_sem) when adding trace event When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values. If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel. The addition of the event should take the trace_event_sem for write while it adds the new event. Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38494", "url": "https://ubuntu.com/security/CVE-2025-38494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: do not bypass hid_hw_raw_request hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38495", "url": "https://ubuntu.com/security/CVE-2025-38495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: ensure the allocated report buffer can contain the reserved report ID When the report ID is not used, the low level transport drivers expect the first byte to be 0. However, currently the allocated buffer not account for that extra byte, meaning that instead of having 8 guaranteed bytes for implement to be working, we only have 7.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38496", "url": "https://ubuntu.com/security/CVE-2025-38496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-bufio: fix sched in atomic context If \"try_verify_in_tasklet\" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spin_lock_bh, the following warning is hit: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table \"0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 1 sha256 1 try_verify_in_tasklet\" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt]", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38497", "url": "https://ubuntu.com/security/CVE-2025-38497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Fix OOB read on empty string write When writing an empty string to either 'qw_sign' or 'landingPage' sysfs attributes, the store functions attempt to access page[l - 1] before validating that the length 'l' is greater than zero. This patch fixes the vulnerability by adding a check at the beginning of os_desc_qw_sign_store() and webusb_landingPage_store() to handle the zero-length input case gracefully by returning immediately.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38535", "url": "https://ubuntu.com/security/CVE-2025-38535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code assumed that the regulator should be disabled. However, if the regulator is marked as always-on, regulator_is_enabled() continues to return true, leading to an incorrect attempt to disable a regulator which is not enabled. This can result in warnings such as: [ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004 _regulator_disable+0xe4/0x1a0 [ 250.155652] unbalanced disables for VIN_SYS_5V0 To fix this, we move the regulator control logic into tegra186_xusb_padctl_id_override() function since it's directly related to the ID override state. The regulator is now only disabled when the role transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID register. This ensures that regulator enable/disable operations are properly balanced and only occur when actually transitioning to/from host mode.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38507", "url": "https://ubuntu.com/security/CVE-2025-38507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: avoid bluetooth suspend/resume stalls Ensure we don't stall or panic the kernel when using bluetooth-connected controllers. This was reported as an issue on android devices using kernel 6.6 due to the resume hook which had been added for usb joycons. First, set a new state value to JOYCON_CTLR_STATE_SUSPENDED in a newly-added nintendo_hid_suspend. This makes sure we will not stall out the kernel waiting for input reports during led classdev suspend. The stalls could happen if connectivity is unreliable or lost to the controller prior to suspend. Second, since we lose connectivity during suspend, do not try joycon_init() for bluetooth controllers in the nintendo_hid_resume path. Tested via multiple suspend/resume flows when using the controller both in USB and bluetooth modes.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38511", "url": "https://ubuntu.com/security/CVE-2025-38511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Clear all LMTT pages on alloc Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages. Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap. While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle. (cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38520", "url": "https://ubuntu.com/security/CVE-2025-38520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Don't call mmput from MMU notifier callback If the process is exiting, the mmput inside mmu notifier callback from compactd or fork or numa balancing could release the last reference of mm struct to call exit_mmap and free_pgtable, this triggers deadlock with below backtrace. The deadlock will leak kfd process as mmu notifier release is not called and cause VRAM leaking. The fix is to take mm reference mmget_non_zero when adding prange to the deferred list to pair with mmput in deferred list work. If prange split and add into pchild list, the pchild work_item.mm is not used, so remove the mm parameter from svm_range_unmap_split and svm_range_add_child. The backtrace of hung task: INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu] (cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38521", "url": "https://ubuntu.com/security/CVE-2025-38521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix kernel crash when hard resetting the GPU The GPU hard reset sequence calls pm_runtime_force_suspend() and pm_runtime_force_resume(), which according to their documentation should only be used during system-wide PM transitions to sleep states. The main issue though is that depending on some internal runtime PM state as seen by pm_runtime_force_suspend() (whether the usage count is <= 1), pm_runtime_force_resume() might not resume the device unless needed. If that happens, the runtime PM resume callback pvr_power_device_resume() is not called, the GPU clocks are not re-enabled, and the kernel crashes on the next attempt to access GPU registers as part of the power-on sequence. Replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume() with direct calls to the driver's runtime PM callbacks, pvr_power_device_suspend() and pvr_power_device_resume(), to ensure clocks are re-enabled and avoid the kernel crash.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38506", "url": "https://ubuntu.com/security/CVE-2025-38506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Allow CPU to reschedule while setting per-page memory attributes When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+), the host can experience CPU soft lockups when running an operation in kvm_vm_set_mem_attributes() to set memory attributes on the whole range of guest memory. watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372] CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary) Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024 RIP: 0010:xas_create+0x78/0x1f0 Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87 RSP: 0018:ffffad890a34b940 EFLAGS: 00000286 RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000 RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868 R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868 FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: xas_store+0x58/0x630 __xa_store+0xa5/0x130 xa_store+0x2c/0x50 kvm_vm_set_mem_attributes+0x343/0x710 [kvm] kvm_vm_ioctl+0x796/0xab0 [kvm] __x64_sys_ioctl+0xa3/0xd0 do_syscall_64+0x8c/0x7a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f5578d031bb Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b RBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000 R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120 R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0 While looping through the range of memory setting the attributes, call cond_resched() to give the scheduler a chance to run a higher priority task on the runqueue if necessary and avoid staying in kernel mode long enough to trigger the lockup.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38104", "url": "https://ubuntu.com/security/CVE-2025-38104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV RLCG Register Access is a way for virtual functions to safely access GPU registers in a virtualized environment., including TLB flushes and register reads. When multiple threads or VFs try to access the same registers simultaneously, it can lead to race conditions. By using the RLCG interface, the driver can serialize access to the registers. This means that only one thread can access the registers at a time, preventing conflicts and ensuring that operations are performed correctly. Additionally, when a low-priority task holds a mutex that a high-priority task needs, ie., If a thread holding a spinlock tries to acquire a mutex, it can lead to priority inversion. register access in amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical. The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being called, which attempts to acquire the mutex. This function is invoked from amdgpu_sriov_wreg, which in turn is called from gmc_v11_0_flush_gpu_tlb. The [ BUG: Invalid wait context ] indicates that a thread is trying to acquire a mutex while it is in a context that does not allow it to sleep (like holding a spinlock). Fixes the below: [ 253.013423] ============================= [ 253.013434] [ BUG: Invalid wait context ] [ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE [ 253.013464] ----------------------------- [ 253.013475] kworker/0:1/10 is trying to lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.013815] other info that might help us debug this: [ 253.013827] context-{4:4} [ 253.013835] 3 locks held by kworker/0:1/10: [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680 [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680 [ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024 [ 253.014224] Workqueue: events work_for_cpu_fn [ 253.014241] Call Trace: [ 253.014250] [ 253.014260] dump_stack_lvl+0x9b/0xf0 [ 253.014275] dump_stack+0x10/0x20 [ 253.014287] __lock_acquire+0xa47/0x2810 [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014562] ? __lock_acquire+0xa6b/0x2810 [ 253.014578] __mutex_lock+0x85/0xe20 [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014782] ? sched_clock_noinstr+0x9/0x10 [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014808] ? local_clock_noinstr+0xe/0xc0 [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.015029] mutex_lock_nested+0x1b/0x30 [ 253.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu] [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu] [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu] [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu] [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu] [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu] [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu] [ 253.0170 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-38067", "url": "https://ubuntu.com/security/CVE-2025-38067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rseq: Fix segfault on registration when rseq_cs is non-zero The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs. The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs. What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-37984", "url": "https://ubuntu.com/security/CVE-2025-37984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8): X / 8 + !!(X & 7) Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values. Additionally, use the macro in ecc_digits_from_bytes(), whose \"nbytes\" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs().", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-38437", "url": "https://ubuntu.com/security/CVE-2025-38437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potential use-after-free in oplock/lease break ack If ksmbd_iov_pin_rsp return error, use-after-free can happen by accessing opinfo->state and opinfo_put and ksmbd_fd_put could called twice.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38510", "url": "https://ubuntu.com/security/CVE-2025-38510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kasan: remove kasan_find_vm_area() to prevent possible deadlock find_vm_area() couldn't be called in atomic_context. If find_vm_area() is called to reports vm area information, kasan can trigger deadlock like: CPU0 CPU1 vmalloc(); alloc_vmap_area(); spin_lock(&vn->busy.lock) spin_lock_bh(&some_lock); spin_lock(&some_lock); kasan_report(); print_report(); print_address_description(); kasan_find_vm_area(); find_vm_area(); spin_lock(&vn->busy.lock) // deadlock! To prevent possible deadlock while kasan reports, remove kasan_find_vm_area().", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38503", "url": "https://ubuntu.com/security/CVE-2025-38503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix assertion when building free space tree When building the free space tree with the block group tree feature enabled, we can hit an assertion failure like this: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]--- This happens because we are processing an empty block group, which has no extents allocated from it, there are no items for this block group, including the block group item since block group items are stored in a dedicated tree when using the block group tree feature. It also means this is the block group with the highest start offset, so there are no higher keys in the extent root, hence btrfs_search_slot_for_read() returns 1 (no higher key found). Fix this by asserting 'ret' is 0 only if the block group tree feature is not enabled, in which case we should find a block group item for the block group since it's stored in the extent root and block group item keys are greater than extent item keys (the value for BTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and BTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively). In case 'ret' is 1, we just need to add a record to the free space tree which spans the whole block group, and we can achieve this by making 'ret == 0' as the while loop's condition.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38439", "url": "https://ubuntu.com/security/CVE-2025-38439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT When transmitting an XDP_REDIRECT packet, call dma_unmap_len_set() with the proper length instead of 0. This bug triggers this warning on a system with IOMMU enabled: WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170 RIP: 0010:__iommu_dma_unmap+0x159/0x170 Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45 b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ff22d31181150c88 EFLAGS: 00010206 RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000 R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000 R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00 FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0 PKRU: 55555554 Call Trace: ? show_regs+0x6d/0x80 ? __warn+0x89/0x160 ? __iommu_dma_unmap+0x159/0x170 ? report_bug+0x17e/0x1b0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x18/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? __iommu_dma_unmap+0x159/0x170 ? __iommu_dma_unmap+0xb3/0x170 iommu_dma_unmap_page+0x4f/0x100 dma_unmap_page_attrs+0x52/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? xdp_return_frame+0x2e/0xd0 bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en] __bnxt_poll_work_done+0x81/0x1e0 [bnxt_en] bnxt_poll+0xd3/0x1e0 [bnxt_en]", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38542", "url": "https://ubuntu.com/security/CVE-2025-38542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: Fix device refcount leak in atrtr_create() When updating an existing route entry in atrtr_create(), the old device reference was not being released before assigning the new device, leading to a device refcount leak. Fix this by calling dev_put() to release the old device reference before holding the new one.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38441", "url": "https://ubuntu.com/security/CVE-2025-38441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto() syzbot found a potential access to uninit-value in nf_flow_pppoe_proto() Blamed commit forgot the Ethernet header. BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5742 [inline] __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837 __netif_receive_skb_one_core net/core/dev.c:5975 [inline] __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090 netif_receive_skb_internal net/core/dev.c:6176 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6235 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xb4b/0x1580 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline]", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38443", "url": "https://ubuntu.com/security/CVE-2025-38443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix uaf in nbd_genl_connect() error path There is a use-after-free issue in nbd: block nbd6: Receive control failed (result -104) block nbd6: shutting down sockets ================================================================== BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022 Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67 CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: nbd6-recv recv_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 nbd_genl_connect() does not properly stop the device on certain error paths after nbd_start_device() has been called. This causes the error path to put nbd->config while recv_work continue to use the config after putting it, leading to use-after-free in recv_work. This patch moves nbd_start_device() after the backend file creation.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38444", "url": "https://ubuntu.com/security/CVE-2025-38444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: raid10: cleanup memleak at raid10_make_request If raid10_read_request or raid10_write_request registers a new request and the REQ_NOWAIT flag is set, the code does not free the malloc from the mempool. unreferenced object 0xffff8884802c3200 (size 192): comm \"fio\", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7e V4: changing backing tree to see if CKI tests will pass. The patch code has not changed between any versions.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38445", "url": "https://ubuntu.com/security/CVE-2025-38445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { \t// newpool is on the stack \tmempool_t newpool, oldpool; \t// initialize newpool.wait.head to stack address \tmempool_init(&newpool, ...); \tconf->r1bio_pool = newpool; } raid1_read_request() or raid1_write_request() { \talloc_r1bio() \t{ \t\tmempool_alloc() \t\t{ \t\t\t// if pool->alloc fails \t\t\tremove_element() \t\t\t{ \t\t\t\t--pool->curr_nr; \t\t\t} \t\t} \t} } mempool_free() { \tif (pool->curr_nr < pool->min_nr) { \t\t// pool->wait.head is a stack address \t\t// wake_up() will try to access this invalid address \t\t// which leads to a kernel panic \t\treturn; \t\twake_up(&pool->wait); \t} } Fix: reinit conf->r1bio_pool.wait after assigning newpool.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38543", "url": "https://ubuntu.com/security/CVE-2025-38543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: nvdec: Fix dma_alloc_coherent error check Check for NULL return value with dma_alloc_coherent, in line with Robin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38513", "url": "https://ubuntu.com/security/CVE-2025-38513", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev() There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For example, the following is possible: \tT0\t\t\t \t\tT1 zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { \t\t\t\t\t filter_ack() \t\t\t\t\t spin_lock_irqsave(&q->lock, flags); \t\t\t\t\t /* position == skb_queue_len(q) */ \t\t\t\t\t for (i=1; itype == NL80211_IFTYPE_AP) \t\t\t\t\t skb = __skb_dequeue(q); \t\t\t\t\t spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULL Since there is a small gap between checking skb queue length and skb being unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL. Then the pointer is passed to zd_mac_tx_status() where it is dereferenced. In order to avoid potential NULL pointer dereference due to situations like above, check if skb is not NULL before passing it to zd_mac_tx_status(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38448", "url": "https://ubuntu.com/security/CVE-2025-38448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Fix race condition in TTY wakeup A race condition occurs when gs_start_io() calls either gs_start_rx() or gs_start_tx(), as those functions briefly drop the port_lock for usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear port.tty and port_usb, respectively. Use the null-safe TTY Port helper function to wake up TTY. Example CPU1:\t\t\t CPU2: gserial_connect() // lock \t\t\t gs_close() // await lock gs_start_rx() // unlock usb_ep_queue() \t\t\t gs_close() // lock, reset port.tty and unlock gs_start_rx() // lock tty_wakeup() // NPE", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38515", "url": "https://ubuntu.com/security/CVE-2025-38515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Increment job count before swapping tail spsc queue A small race exists between spsc_queue_push and the run-job worker, in which spsc_queue_push may return not-first while the run-job worker has already idled due to the job count being zero. If this race occurs, job scheduling stops, leading to hangs while waiting on the job’s DMA fences. Seal this race by incrementing the job count before appending to the SPSC queue. This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in an SVM test case.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38449", "url": "https://ubuntu.com/security/CVE-2025-38449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Acquire references on GEM handles for framebuffers A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below. [ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]--- Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references. Commit 1a148af06000 (\"drm/gem-shmem: Use dma_buf from GEM object instance\") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before. v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38512", "url": "https://ubuntu.com/security/CVE-2025-38512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: prevent A-MSDU attacks in mesh networks This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks. This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt. This defense was tested with mac80211_hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field. It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented. Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation: https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38516", "url": "https://ubuntu.com/security/CVE-2025-38516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: qcom: msm: mark certain pins as invalid for interrupts On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: `gpiomon -c 0 113` on RB2. The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs. This function can be extended if we determine that there are more corner-cases like this.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38455", "url": "https://ubuntu.com/security/CVE-2025-38455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight Reject migration of SEV{-ES} state if either the source or destination VM is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the section between incrementing created_vcpus and online_vcpus. The bulk of vCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUs in parallel, and so sev_info.es_active can get toggled from false=>true in the destination VM after (or during) svm_vcpu_create(), resulting in an SEV{-ES} VM effectively having a non-SEV{-ES} vCPU. The issue manifests most visibly as a crash when trying to free a vCPU's NULL VMSA page in an SEV-ES VM, but any number of things can go wrong. BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 __fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]--- Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38456", "url": "https://ubuntu.com/security/CVE-2025-38456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:msghandler: Fix potential memory corruption in ipmi_create_user() The \"intf\" list iterator is an invalid pointer if the correct \"intf->intf_num\" is not found. Calling atomic_dec(&intf->nr_users) on and invalid pointer will lead to memory corruption. We don't really need to call atomic_dec() if we haven't called atomic_add_return() so update the if (intf->in_shutdown) path as well.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38514", "url": "https://ubuntu.com/security/CVE-2025-38514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix oops due to non-existence of prealloc backlog struct If an AF_RXRPC service socket is opened and bound, but calls are preallocated, then rxrpc_alloc_incoming_call() will oops because the rxrpc_backlog struct doesn't get allocated until the first preallocation is made. Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no backlog struct. This will cause the incoming call to be aborted.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38544", "url": "https://ubuntu.com/security/CVE-2025-38544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix bug due to prealloc collision When userspace is using AF_RXRPC to provide a server, it has to preallocate incoming calls and assign to them call IDs that will be used to thread related recvmsg() and sendmsg() together. The preallocated call IDs will automatically be attached to calls as they come in until the pool is empty. To the kernel, the call IDs are just arbitrary numbers, but userspace can use the call ID to hold a pointer to prepared structs. In any case, the user isn't permitted to create two calls with the same call ID (call IDs become available again when the call ends) and EBADSLT should result from sendmsg() if an attempt is made to preallocate a call with an in-use call ID. However, the cleanup in the error handling will trigger both assertions in rxrpc_cleanup_call() because the call isn't marked complete and isn't marked as having been released. Fix this by setting the call state in rxrpc_service_prealloc_one() and then marking it as being released before calling the cleanup function.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38457", "url": "https://ubuntu.com/security/CVE-2025-38457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Abort __tc_modify_qdisc if parent class does not exist Lion's patch [1] revealed an ancient bug in the qdisc API. Whenever a user creates/modifies a qdisc specifying as a parent another qdisc, the qdisc API will, during grafting, detect that the user is not trying to attach to a class and reject. However grafting is performed after qdisc_create (and thus the qdiscs' init callback) is executed. In qdiscs that eventually call qdisc_tree_reduce_backlog during init or change (such as fq, hhf, choke, etc), an issue arises. For example, executing the following commands: sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq Qdiscs such as fq, hhf, choke, etc unconditionally invoke qdisc_tree_reduce_backlog() in their control path init() or change() which then causes a failure to find the child class; however, that does not stop the unconditional invocation of the assumed child qdisc's qlen_notify with a null class. All these qdiscs make the assumption that class is non-null. The solution is ensure that qdisc_leaf() which looks up the parent class, and is invoked prior to qdisc_create(), should return failure on not finding the class. In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the parentid doesn't correspond to a class, so that we can detect it earlier on and abort before qdisc_create is called. [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38458", "url": "https://ubuntu.com/security/CVE-2025-38458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix NULL pointer dereference in vcc_sendmsg() atmarpd_dev_ops does not implement the send method, which may cause crash as bellow. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246 RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000 RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000 RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287 R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00 R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88 FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38459", "url": "https://ubuntu.com/security/CVE-2025-38459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix infinite recursive call of clip_push(). syzbot reported the splat below. [0] This happens if we call ioctl(ATMARP_MKIP) more than once. During the first call, clip_mkip() sets clip_push() to vcc->push(), and the second call copies it to clip_vcc->old_push(). Later, when the socket is close()d, vcc_destroy_socket() passes NULL skb to clip_push(), which calls clip_vcc->old_push(), triggering the infinite recursion. Let's prevent the second ioctl(ATMARP_MKIP) by checking vcc->user_back, which is allocated by the first call as clip_vcc. Note also that we use lock_sock() to prevent racy calls. [0]: BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000) Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00 RSP: 0018:ffffc9000d670000 EFLAGS: 00010246 RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000 RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300 R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0 Call Trace: clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 ... clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 vcc_destroy_socket net/atm/common.c:183 [inline] vcc_release+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff31c98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 Modules linked in:", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38546", "url": "https://ubuntu.com/security/CVE-2025-38546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix memory leak of struct clip_vcc. ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it to vcc->user_back. The code assumes that vcc_destroy_socket() passes NULL skb to vcc->push() when the socket is close()d, and then clip_push() frees clip_vcc. However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() in atm_init_atmarp(), resulting in memory leak. Let's serialise two ioctl() by lock_sock() and check vcc->push() in atm_init_atmarp() to prevent memleak.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38460", "url": "https://ubuntu.com/security/CVE-2025-38460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix potential null-ptr-deref in to_atmarpd(). atmarpd is protected by RTNL since commit f3a0592b37b8 (\"[ATM]: clip causes unregister hang\"). However, it is not enough because to_atmarpd() is called without RTNL, especially clip_neigh_solicit() / neigh_ops->solicit() is unsleepable. Also, there is no RTNL dependency around atmarpd. Let's use a private mutex and RCU to protect access to atmarpd in to_atmarpd().", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38461", "url": "https://ubuntu.com/security/CVE-2025-38461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_* TOCTOU Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer. This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38462", "url": "https://ubuntu.com/security/CVE-2025-38462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_{g2h,h2g} TOCTOU vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload. transport_{g2h,h2g} may become NULL after the NULL check. Introduce vsock_transport_local_cid() to protect from a potential null-ptr-deref. KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_find_cid+0x47/0x90 Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0 Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38463", "url": "https://ubuntu.com/security/CVE-2025-38463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtraction will result in copy holding a very large positive integer. In the subsequent logic, this large value is used to update sk->sk_forward_alloc, which can easily cause it to overflow. The syzkaller reproducer uses TCP_REPAIR to reliably create this condition. However, this can also occur in real-world scenarios. The tcp_bound_to_half_wnd() function can also reduce size_goal to a small value. This would cause the subsequent tcp_wmem_schedule() to set sk->sk_forward_alloc to a value close to INT_MAX. Further memory allocation requests would then cause sk_forward_alloc to wrap around and become negative. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38464", "url": "https://ubuntu.com/security/CVE-2025-38464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_conn_close(). syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0] tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn. The problem is that tipc_conn_close() is called after releasing the IDR lock. At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref. Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive. Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop(). [0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435 CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38465", "url": "https://ubuntu.com/security/CVE-2025-38465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: Fix wraparounds of sk->sk_rmem_alloc. Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) \tatomic_add(skb->truesize, &sk->sk_rmem_alloc); , which has the same problem fixed by commit 5a465a0da13e (\"udp: Fix multiple wraparounds of sk->sk_rmem_alloc.\"). For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition is always false as the two operands are of int. Then, a single socket can eat as many skb as possible until OOM happens, and we can see multiple wraparounds of sk->sk_rmem_alloc. Let's fix it by using atomic_add_return() and comparing the two variables as unsigned int. Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 * After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38466", "url": "https://ubuntu.com/security/CVE-2025-38466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Revert to requiring CAP_SYS_ADMIN for uprobes Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream. Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction. As such, require CAP_SYS_ADMIN for uprobes.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38467", "url": "https://ubuntu.com/security/CVE-2025-38467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling If there's support for another console device (such as a TTY serial), the kernel occasionally panics during boot. The panic message and a relevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...] Otherwise, the panics don't happen. This indicates that it's some sort of race condition. Add a check to validate if the drm device can handle vblanks before calling drm_crtc_handle_vblank() to avoid this.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38349", "url": "https://ubuntu.com/security/CVE-2025-38349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to \"ep_free(ep)\" until after it has unlocked the mutex. But it's wrong for the much subtler \"next to last\" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex \"unlock\" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: \t\"mutex_unlock() may access the mutex structure even after it has \t internally released the lock already - so it's not safe for \t another context to acquire the mutex and assume that the \t mutex_unlock() context is not using the structure anymore\" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).", "cve_priority": "medium", "cve_public_date": "2025-07-18 08:15:00 UTC" }, { "cve": "CVE-2025-38407", "url": "https://ubuntu.com/security/CVE-2025-38407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: cpu_ops_sbi: Use static array for boot_data Since commit 6b9f29b81b15 (\"riscv: Enable pcpu page first chunk allocator\"), if NUMA is enabled, the page percpu allocator may be used on very sparse configurations, or when requested on boot with percpu_alloc=page. In that case, percpu data gets put in the vmalloc area. However, sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data, and simply assumes that __pa() would work. This causes the just started hart to immediately access an invalid address and hang. Fortunately, struct sbi_hart_boot_data is not too large, so we can simply allocate an array for boot_data statically, putting it in the kernel image. This fixes NUMA=y SMP boot on Sophgo SG2042. To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then run with: qemu-system-riscv64 -M virt -smp 2 -nographic \\ -kernel arch/riscv/boot/Image \\ -append \"percpu_alloc=page\" Kernel output: [ 0.000000] Booting Linux on hartid 0 [ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025 ... [ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712 ... [ 0.083192] smp: Bringing up secondary CPUs ... [ 0.086722] ------------[ cut here ]------------ [ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080) [ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8 [ 0.088376] Modules linked in: [ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE [ 0.088833] Hardware name: riscv-virtio,qemu (DT) [ 0.088948] epc : __virt_to_phys+0xae/0xe8 [ 0.089001] ra : __virt_to_phys+0xae/0xe8 [ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0 [ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976 [ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0 [ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000 [ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000 [ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001 [ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec [ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000 [ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7 [ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8 [ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003 [ 0.090101] [] __virt_to_phys+0xae/0xe8 [ 0.090228] [] sbi_cpu_start+0x6e/0xe8 [ 0.090247] [] __cpu_up+0x1e/0x8c [ 0.090260] [] bringup_cpu+0x42/0x258 [ 0.090277] [] cpuhp_invoke_callback+0xe0/0x40c [ 0.090292] [] __cpuhp_invoke_callback_range+0x68/0xfc [ 0.090320] [] _cpu_up+0x11a/0x244 [ 0.090334] [] cpu_up+0x52/0x90 [ 0.090384] [] bringup_nonboot_cpus+0x78/0x118 [ 0.090411] [] smp_init+0x34/0xb8 [ 0.090425] [] kernel_init_freeable+0x148/0x2e4 [ 0.090442] [] kernel_init+0x1e/0x14c [ 0.090455] [] ret_from_fork_kernel+0xe/0xf0 [ 0.090471] [] ret_from_fork_kernel_asm+0x16/0x18 [ 0.090560] ---[ end trace 0000000000000000 ]--- [ 1.179875] CPU1: failed to come online [ 1.190324] smp: Brought up 1 node, 1 CPU", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38374", "url": "https://ubuntu.com/security/CVE-2025-38374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: optee: ffa: fix sleep in atomic context The OP-TEE driver registers the function notif_callback() for FF-A notifications. However, this function is called in an atomic context leading to errors like this when processing asynchronous notifications: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13 | Hardware name: linux,dummy-virt (DT) | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | optee_get_msg_arg+0x7c/0x21c | simple_call_with_arg+0x50/0xc0 | optee_do_bottom_half+0x14/0x20 | notif_callback+0x3c/0x48 | handle_notif_callbacks+0x9c/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 Fix this by adding work queue to process the notification in a non-atomic context.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38373", "url": "https://ubuntu.com/security/CVE-2025-38373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix potential deadlock in MR deregistration The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock. The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | → revoke_mr() | → mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | → mutex_lock(&dev->cache.rb_lock) | → mlx5r_cache_create_ent_locked() | → kzalloc(GFP_KERNEL) | → fs_reclaim() | → mmu_notifier_invalidate_range_start() | → mlx5_ib_invalidate_range() | → mutex_lock(&umem_odp->umem_mutex) → cache_ent_find_and_store() | → mutex_lock(&dev->cache.rb_lock) | Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex. Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path. This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path. The following lockdep warning demonstrates the deadlock: python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38408", "url": "https://ubuntu.com/security/CVE-2025-38408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38279", "url": "https://ubuntu.com/security/CVE-2025-38279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not include stack ptr register in precision backtracking bookkeeping Yi Lai reported an issue ([1]) where the following warning appears in kernel dmesg: [ 60.643604] verifier backtracking bug [ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 [ 60.648428] Modules linked in: bpf_testmod(OE) [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246 [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000 [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8 [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0 [ 60.691623] Call Trace: [ 60.692821] [ 60.693960] ? __pfx_verbose+0x10/0x10 [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ... Further analysis shows the warning is at line 4302 as below: 4294 /* static subprog call instruction, which 4295 * means that we are exiting current subprog, 4296 * so only r1-r5 could be still requested as 4297 * precise, r0 and r6-r10 or any stack slot in 4298 * the current frame should be zero by now 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env, \"BUG regs %x\\n\", bt_reg_mask(bt)); 4302 WARN_ONCE(1, \"verifier backtracking bug\"); 4303 return -EFAULT; 4304 } With the below test (also in the next patch): __used __naked static void __bpf_jmp_r10(void) { \tasm volatile ( \t\"r2 = 2314885393468386424 ll;\" \t\"goto +0;\" \t\"if r2 <= r10 goto +3;\" \t\"if r1 >= -1835016 goto +0;\" \t\"if r2 <= 8 goto +0;\" \t\"if r3 <= 0 goto +0;\" \t\"exit;\" \t::: __clobber_all); } SEC(\"?raw_tp\") __naked void bpf_jmp_r10(void) { \tasm volatile ( \t\"r3 = 0 ll;\" \t\"call __bpf_jmp_r10;\" \t\"r0 = 0;\" \t\"exit;\" \t::: __clobber_all); } The following is the verifier failure log: 0: (18) r3 = 0x0 ; R3_w=0 2: (85) call pc+2 caller: R10=fp0 callee: frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile (\" \\ @ verifier_precision.c:184 5: (18) r2 = 0x20202000256c6c78 ; frame1: R2_w=0x20202000256c6c78 7: (05) goto pc+0 8: (bd) if r2 <= r10 goto pc+3 ; frame1: R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1 mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 <= r10 goto pc+3 mark_preci ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38289", "url": "https://ubuntu.com/security/CVE-2025-38289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbk Smatch detected a potential use-after-free of an ndlp oject in dev_loss_tmo_callbk during driver unload or fatal error handling. Fix by reordering code to avoid potential use-after-free if initial nodelist reference has been previously removed.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38392", "url": "https://ubuntu.com/security/CVE-2025-38392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: convert control queue mutex to a spinlock With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated on module load: [ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578 [ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager [ 324.701689] preempt_count: 201, expected: 0 [ 324.701693] RCU nest depth: 0, expected: 0 [ 324.701697] 2 locks held by NetworkManager/1582: [ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0 [ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870 [ 324.701749] Preemption disabled at: [ 324.701752] [] __dev_open+0x3dd/0x870 [ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary) [ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022 [ 324.701774] Call Trace: [ 324.701777] [ 324.701779] dump_stack_lvl+0x5d/0x80 [ 324.701788] ? __dev_open+0x3dd/0x870 [ 324.701793] __might_resched.cold+0x1ef/0x23d <..> [ 324.701818] __mutex_lock+0x113/0x1b80 <..> [ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf] [ 324.701935] ? kasan_save_track+0x14/0x30 [ 324.701941] idpf_mb_clean+0x143/0x380 [idpf] <..> [ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf] [ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf] [ 324.702021] ? rcu_is_watching+0x12/0xc0 [ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf] <..> [ 324.702122] __hw_addr_sync_dev+0x1cf/0x300 [ 324.702126] ? find_held_lock+0x32/0x90 [ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf] [ 324.702152] __dev_open+0x3f8/0x870 [ 324.702159] ? __pfx___dev_open+0x10/0x10 [ 324.702174] __dev_change_flags+0x443/0x650 <..> [ 324.702208] netif_change_flags+0x80/0x160 [ 324.702218] do_setlink.isra.0+0x16a0/0x3960 <..> [ 324.702349] rtnl_newlink+0x12fd/0x21e0 The sequence is as follows: \trtnl_newlink()-> \t__dev_change_flags()-> \t__dev_open()-> \tdev_set_rx_mode() - > # disables BH and grabs \"dev->addr_list_lock\" \tidpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON \t__dev_uc_sync() -> \tidpf_add_mac_filter -> \tidpf_add_del_mac_filters -> \tidpf_send_mb_msg() -> \tidpf_mb_clean() -> \tidpf_ctlq_clean_sq() # mutex_lock(cq_lock) Fix by converting cq_lock to a spinlock. All operations under the new lock are safe except freeing the DMA memory, which may use vunmap(). Fix by requesting a contiguous physical memory for the DMA mapping.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38402", "url": "https://ubuntu.com/security/CVE-2025-38402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: return 0 size for RSS key if not supported Returning -EOPNOTSUPP from function returning u32 is leading to cast and invalid size value as a result. -EOPNOTSUPP as a size probably will lead to allocation fail. Command: ethtool -x eth0 It is visible on all devices that don't have RSS caps set. [ 136.615917] Call Trace: [ 136.615921] [ 136.615927] ? __warn+0x89/0x130 [ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330 [ 136.615953] ? report_bug+0x164/0x190 [ 136.615968] ? handle_bug+0x58/0x90 [ 136.615979] ? exc_invalid_op+0x17/0x70 [ 136.615987] ? asm_exc_invalid_op+0x1a/0x20 [ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330 [ 136.616028] __alloc_pages_noprof+0xe/0x20 [ 136.616038] ___kmalloc_large_node+0x80/0x110 [ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0 [ 136.616081] __kmalloc_noprof+0x32c/0x4c0 [ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616114] ethnl_default_doit+0x107/0x3d0 [ 136.616131] genl_family_rcv_msg_doit+0x100/0x160 [ 136.616147] genl_rcv_msg+0x1b8/0x2c0 [ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10 [ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10 [ 136.616176] netlink_rcv_skb+0x58/0x110 [ 136.616186] genl_rcv+0x28/0x40 [ 136.616195] netlink_unicast+0x19b/0x290 [ 136.616206] netlink_sendmsg+0x222/0x490 [ 136.616215] __sys_sendto+0x1fd/0x210 [ 136.616233] __x64_sys_sendto+0x24/0x30 [ 136.616242] do_syscall_64+0x82/0x160 [ 136.616252] ? __sys_recvmsg+0x83/0xe0 [ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210 [ 136.616275] ? do_syscall_64+0x8e/0x160 [ 136.616282] ? __count_memcg_events+0xa1/0x130 [ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30 [ 136.616306] ? handle_mm_fault+0xae/0x2d0 [ 136.616319] ? do_user_addr_fault+0x379/0x670 [ 136.616328] ? clear_bhb_loop+0x45/0xa0 [ 136.616340] ? clear_bhb_loop+0x45/0xa0 [ 136.616349] ? clear_bhb_loop+0x45/0xa0 [ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 136.616369] RIP: 0033:0x7fd30ba7b047 [ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44 [ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047 [ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003 [ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c [ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340 [ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38405", "url": "https://ubuntu.com/security/CVE-2025-38405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix memory leak of bio integrity If nvmet receives commands with metadata there is a continuous memory leak of kmalloc-128 slab or more precisely bio->bi_integrity. Since commit bf4c89fc8797 (\"block: don't call bio_uninit from bio_endio\") each user of bio_init has to use bio_uninit as well. Otherwise the bio integrity is not getting free. Nvmet uses bio_init for inline bios. Uninit the inline bio to complete deallocation of integrity in bio.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38388", "url": "https://ubuntu.com/security/CVE-2025-38388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It results in the below kernel warnings: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 To address this, replace the mutex with an rwlock to protect the notifier hashtable accesses. This ensures that read-side locking does not sleep and multiple readers can acquire the lock concurrently, avoiding unnecessary contention and potential deadlocks. Writer access remains exclusive, preserving correctness. This change resolves warnings from lockdep about potential sleep in atomic context.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38390", "url": "https://ubuntu.com/security/CVE-2025-38390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix memory leak by freeing notifier callback node Commit e0573444edbf (\"firmware: arm_ffa: Add interfaces to request notification callbacks\") adds support for notifier callbacks by allocating and inserting a callback node into a hashtable during registration of notifiers. However, during unregistration, the code only removes the node from the hashtable without freeing the associated memory, resulting in a memory leak. Resolve the memory leak issue by ensuring the allocated notifier callback node is properly freed after it is removed from the hashtable entry.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2024-36350", "url": "https://ubuntu.com/security/CVE-2024-36350", "cve_description": "A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information.", "cve_priority": "medium", "cve_public_date": "2025-07-08 17:15:00 UTC" }, { "cve": "CVE-2024-36357", "url": "https://ubuntu.com/security/CVE-2024-36357", "cve_description": "A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.", "cve_priority": "medium", "cve_public_date": "2025-07-08 17:15:00 UTC" }, { "cve": "CVE-2025-38376", "url": "https://ubuntu.com/security/CVE-2025-38376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume Shawn and John reported a hang issue during system suspend as below: - USB gadget is enabled as Ethernet - There is data transfer over USB Ethernet (scp a big file between host and device) - Device is going in/out suspend (echo mem > /sys/power/state) The root cause is the USB device controller is suspended but the USB bus is still active which caused the USB host continues to transfer data with device and the device continues to queue USB requests (in this case, a delayed TCP ACK packet trigger the issue) after controller is suspended, however the USB controller clock is already gated off. Then if udc driver access registers after that point, the system will hang. The correct way to avoid such issue is to disconnect device from host when the USB bus is not at suspend state. Then the host will receive disconnect event and stop data transfer in time. To continue make USB gadget device work after system resume, this will reconnect device automatically. To make usb wakeup work if USB bus is already at suspend state, this will keep connection for it only when USB device controller has enabled wakeup capability.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38396", "url": "https://ubuntu.com/security/CVE-2025-38396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass Export anon_inode_make_secure_inode() to allow KVM guest_memfd to create anonymous inodes with proper security context. This replaces the current pattern of calling alloc_anon_inode() followed by inode_init_security_anon() for creating security context manually. This change also fixes a security regression in secretmem where the S_PRIVATE flag was not cleared after alloc_anon_inode(), causing LSM/SELinux checks to be bypassed for secretmem file descriptors. As guest_memfd currently resides in the KVM module, we need to export this symbol for use outside the core kernel. In the future, guest_memfd might be moved to core-mm, at which point the symbols no longer would have to be exported. When/if that happens is still unclear.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38371", "url": "https://ubuntu.com/security/CVE-2025-38371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Disable interrupts before resetting the GPU Currently, an interrupt can be triggered during a GPU reset, which can lead to GPU hangs and NULL pointer dereference in an interrupt context as shown in the following trace: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Before resetting the G ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38384", "url": "https://ubuntu.com/security/CVE-2025-38384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: spinand: fix memory leak of ECC engine conf Memory allocated for the ECC engine conf is not released during spinand cleanup. Below kmemleak trace is seen for this memory leak: unreferenced object 0xffffff80064f00e0 (size 8): comm \"swapper/0\", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160 Fix the leak by calling nanddev_ecc_engine_cleanup() inside spinand_cleanup().", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38386", "url": "https://ubuntu.com/security/CVE-2025-38386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Refuse to evaluate a method if arguments are missing As reported in [1], a platform firmware update that increased the number of method parameters and forgot to update a least one of its callers, caused ACPICA to crash due to use-after-free. Since this a result of a clear AML issue that arguably cannot be fixed up by the interpreter (it cannot produce missing data out of thin air), address it by making ACPICA refuse to evaluate a method if the caller attempts to pass fewer arguments than expected to it.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38406", "url": "https://ubuntu.com/security/CVE-2025-38406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: remove WARN on bad firmware input If the firmware gives bad input, that's nothing to do with the driver's stack at this point etc., so the WARN_ON() doesn't add any value. Additionally, this is one of the top syzbot reports now. Just print a message, and as an added bonus, print the sizes too.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38399", "url": "https://ubuntu.com/security/CVE-2025-38399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port() The function core_scsi3_decode_spec_i_port(), in its error code path, unconditionally calls core_scsi3_lunacl_undepend_item() passing the dest_se_deve pointer, which may be NULL. This can lead to a NULL pointer dereference if dest_se_deve remains unset. SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg Unable to handle kernel paging request at virtual address dfff800000000012 Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod] Fix this by adding a NULL check before calling core_scsi3_lunacl_undepend_item()", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38409", "url": "https://ubuntu.com/security/CVE-2025-38409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix another leak in the submit error path put_unused_fd() doesn't free the installed file, if we've already done fd_install(). So we need to also free the sync_file. Patchwork: https://patchwork.freedesktop.org/patch/653583/", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38410", "url": "https://ubuntu.com/security/CVE-2025-38410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix a fence leak in submit error path In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Patchwork: https://patchwork.freedesktop.org/patch/653584/", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38377", "url": "https://ubuntu.com/security/CVE-2025-38377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rose: fix dangling neighbour pointers in rose_rt_device_down() There are two bugs in rose_rt_device_down() that can cause use-after-free: 1. The loop bound `t->count` is modified within the loop, which can cause the loop to terminate early and miss some entries. 2. When removing an entry from the neighbour array, the subsequent entries are moved up to fill the gap, but the loop index `i` is still incremented, causing the next entry to be skipped. For example, if a node has three neighbours (A, A, B) with count=3 and A is being removed, the second A is not checked. i=0: (A, A, B) -> (A, B) with count=2 ^ checked i=1: (A, B) -> (A, B) with count=2 ^ checked (B, not A!) i=2: (doesn't occur because i < count is false) This leaves the second A in the array with count=2, but the rose_neigh structure has been freed. Code that accesses these entries assumes that the first `count` entries are valid pointers, causing a use-after-free when it accesses the dangling pointer. Fix both issues by iterating over the array in reverse order with a fixed loop bound. This ensures that all entries are examined and that the removal of an entry doesn't affect subsequent iterations.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38389", "url": "https://ubuntu.com/security/CVE-2025-38389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix timeline left held on VMA alloc error The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform: <4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]--- If the test also unloads the i915 module then that's followed with: <3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915_vma_instance+0xee/0xc10 [i915] <4> [357.789290] init_status_page+0x7b/0x420 [i915] <4> [357.789532] intel_engines_init+0x1d8/0x980 [i915] <4> [357.789772] intel_gt_init+0x175/0x450 [i915] <4> [357.790014] i915_gem_init+0x113/0x340 [i915] <4> [357.790281] i915_driver_probe+0x847/0xed0 [i915] <4> [357.790504] i915_pci_probe+0xe6/0x220 [i915] ... Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - igt@api_intel_allocator@fork-simple-stress-signal, - igt@api_intel_allocator@two-level-inception-interruptible, - igt@gem_linear_blits@interruptible, - igt@prime_mmap_coherency@ioctl-errors, which invisibly trigger the issue, then exhibited with first driver unbind attempt. All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring submission, in particular. If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error. In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915_vma_instance() called from inside is interrupted with a signal, then ring_context_alloc() fails, leaving the timeline held referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind. Get the legacy timeline only after successful allocation of the context engine's VMA. v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue. (cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38385", "url": "https://ubuntu.com/security/CVE-2025-38385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect Remove redundant netif_napi_del() call from disconnect path. A WARN may be triggered in __netif_napi_del_locked() during USB device disconnect: WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 This happens because netif_napi_del() is called in the disconnect path while NAPI is still enabled. However, it is not necessary to call netif_napi_del() explicitly, since unregister_netdev() will handle NAPI teardown automatically and safely. Removing the redundant call avoids triggering the warning. Full trace: lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV lan78xx 1-1:1.0 enu1: Link is Down lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 Modules linked in: flexcan can_dev fuse CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT Hardware name: SKOV IMX8MP CPU revC - bd500 (DT) Workqueue: usb_hub_wq hub_event pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __netif_napi_del_locked+0x2b4/0x350 lr : __netif_napi_del_locked+0x7c/0x350 sp : ffffffc085b673c0 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000 Call trace: __netif_napi_del_locked+0x2b4/0x350 (P) lan78xx_disconnect+0xf4/0x360 usb_unbind_interface+0x158/0x718 device_remove+0x100/0x150 device_release_driver_internal+0x308/0x478 device_release_driver+0x1c/0x30 bus_remove_device+0x1a8/0x368 device_del+0x2e0/0x7b0 usb_disable_device+0x244/0x540 usb_disconnect+0x220/0x758 hub_event+0x105c/0x35e0 process_one_work+0x760/0x17b0 worker_thread+0x768/0xce8 kthread+0x3bc/0x690 ret_from_fork+0x10/0x20 irq event stamp: 211604 hardirqs last enabled at (211603): [] _raw_spin_unlock_irqrestore+0x84/0x98 hardirqs last disabled at (211604): [] el1_dbg+0x24/0x80 softirqs last enabled at (211296): [] handle_softirqs+0x820/0xbc8 softirqs last disabled at (210993): [] __do_softirq+0x18/0x20 ---[ end trace 0000000000000000 ]--- lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38412", "url": "https://ubuntu.com/security/CVE-2025-38412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38382", "url": "https://ubuntu.com/security/CVE-2025-38382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix iteration of extrefs during log replay At __inode_add_ref() when processing extrefs, if we jump into the next label we have an undefined value of victim_name.len, since we haven't initialized it before we did the goto. This results in an invalid memory access in the next iteration of the loop since victim_name.len was not initialized to the length of the name of the current extref. Fix this by initializing victim_name.len with the current extref's name length.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38393", "url": "https://ubuntu.com/security/CVE-2025-38393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero. It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f (\"SUNRPC: Fix a race to wake a sync task\"). Fix it up by applying the advised barrier.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38400", "url": "https://ubuntu.com/security/CVE-2025-38400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails. syzbot reported a warning below [1] following a fault injection in nfs_fs_proc_net_init(). [0] When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed. Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning is logged as the directory is not empty. Let's handle the error of nfs_fs_proc_net_init() properly. [0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174) should_failslab (mm/failslab.c:46) kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204) __proc_create (fs/proc/generic.c:427) proc_create_reg (fs/proc/generic.c:554) proc_create_net_data (fs/proc/proc_net.c:120) nfs_fs_proc_net_init (fs/nfs/client.c:1409) nfs_net_init (fs/nfs/inode.c:2600) ops_init (net/core/net_namespace.c:138) setup_net (net/core/net_namespace.c:443) copy_net_ns (net/core/net_namespace.c:576) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4)) ksys_unshare (kernel/fork.c:3123) __x64_sys_unshare (kernel/fork.c:3190) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) [1]: remove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs' WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727 Modules linked in: CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727 Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00 RSP: 0018:ffffc90003637b08 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8 RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001 RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00 R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000 FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76 ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253 setup_net+0x2e1/0x510 net/core/net_namespace.c:457 copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574 create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218 ksys_unshare+0x45b/0xa40 kernel/fork.c:3121 __do_sys_unshare kernel/fork.c:3192 [inline] __se_sys_unshare kernel/fork.c:3190 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa1a6b8e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38387", "url": "https://ubuntu.com/security/CVE-2025-38387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insert The obj_event may be loaded immediately after inserted, then if the list_head is not initialized then we may get a poisonous pointer. This fixes the crash below: mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E) [last unloaded: mst_pci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatch_event_fd+0x68/0x300 [mlx5_ib] lr : devx_event_notifier+0xcc/0x228 [mlx5_ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatch_event_fd+0x68/0x300 [mlx5_ib] devx_event_notifier+0xcc/0x228 [mlx5_ib] atomic_notifier_call_chain+0x58/0x80 mlx5_eq_async_int+0x148/0x2b0 [mlx5_core] atomic_notifier_call_chain+0x58/0x80 irq_int_handler+0x20/0x30 [mlx5_core] __handle_irq_event_percpu+0x60/0x220 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x58/0x158 handle_fasteoi_irq+0xfc/0x188 generic_handle_irq+0x34/0x48 ...", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38401", "url": "https://ubuntu.com/security/CVE-2025-38401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtk-sd: Prevent memory corruption from DMA map failure If msdc_prepare_data() fails to map the DMA region, the request is not prepared for data receiving, but msdc_start_data() proceeds the DMA with previous setting. Since this will lead a memory corruption, we have to stop the request operation soon after the msdc_prepare_data() fails to prepare it.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38391", "url": "https://ubuntu.com/security/CVE-2025-38391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: do not index invalid pin_assignments A poorly implemented DisplayPort Alt Mode port partner can indicate that its pin assignment capabilities are greater than the maximum value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show will cause a BRK exception due to an out of bounds array access. Prevent for loop in pin_assignment_show from accessing invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop condition.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38395", "url": "https://ubuntu.com/security/CVE-2025-38395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But the memory is allocated for only one pointer. This will lead to out-of-bounds access later in the code if 'config::ngpios' is > 1. So fix the code to allocate enough memory to hold 'config::ngpios' of GPIO descriptors. While at it, also move the check for memory allocation failure to be below the allocation to make it more readable.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38403", "url": "https://ubuntu.com/security/CVE-2025-38403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: Clear the vmci transport packet properly when initializing it In vmci_transport_packet_init memset the vmci_transport_packet before populating the fields to avoid any uninitialised data being left in the structure.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38375", "url": "https://ubuntu.com/security/CVE-2025-38375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: ensure the received length does not exceed allocated size In xdp_linearize_page, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-37842", "url": "https://ubuntu.com/security/CVE-2025-37842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl-qspi: use devm function instead of driver remove Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence. Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23155", "url": "https://ubuntu.com/security/CVE-2025-23155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix accessing freed irq affinity_hint In stmmac_request_irq_multi_msi(), a pointer to the stack variable cpu_mask is passed to irq_set_affinity_hint(). This value is stored in irq_desc->affinity_hint, but once stmmac_request_irq_multi_msi() returns, the pointer becomes dangling. The affinity_hint is exposed via procfs with S_IRUGO permissions, allowing any unprivileged process to read it. Accessing this stale pointer can lead to: - a kernel oops or panic if the referenced memory has been released and unmapped, or - leakage of kernel data into userspace if the memory is re-used for other purposes. All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are affected.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-22101", "url": "https://ubuntu.com/security/CVE-2025-22101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix Tx L4 checksum The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol. There was a bug to set Tx checksum flag for the other protocol that results in Tx ring hang. Fix to compute software checksum for these packets.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38361", "url": "https://ubuntu.com/security/CVE-2025-38361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38364", "url": "https://ubuntu.com/security/CVE-2025-38364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate() Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations. The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption. User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least)", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38246", "url": "https://ubuntu.com/security/CVE-2025-38246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: properly flush XDP redirect lists We encountered following crash when testing a XDP_REDIRECT feature in production: [56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cut here ]------------ [56251.611357] kernel BUG at lib/list_debug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] [56251.851943] cpu_map_enqueue.cold+0x5/0xa [56251.860243] xdp_do_redirect+0x2d9/0x480 [56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en] [56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en] [56251.885665] ? cpu_max_write+0x1e/0x100 [56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en] [56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en] [56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.944250] __napi_poll+0x2b/0x160 [56251.951155] bpf_trampoline_6442548651+0x79/0x123 [56251.959262] __napi_poll+0x5/0x160 [56251.966037] net_rx_action+0x3d2/0x880 [56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.989262] ? __hrtimer_run_queues+0x162/0x2a0 [56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en] [56252.019903] handle_softirqs+0xcf/0x270 [56252.026650] irq_exit_rcu+0x67/0x90 [56252.032933] common_interrupt+0x85/0xa0 [56252.039498] [56252.044246] [56252.048935] asm_common_interrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidle_enter_state+0xab/0x420 [56252.153909] cpuidle_enter+0x2d/0x40 [56252.160360] do_idle+0x176/0x1c0 [56252.166456 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38250", "url": "https://ubuntu.com/security/CVE-2025-38250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 (\"Bluetooth: Remove unused hci-destruct cb\"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38253", "url": "https://ubuntu.com/security/CVE-2025-38253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix crash in wacom_aes_battery_handler() Commit fd2a9b29dc9c (\"HID: wacom: Remove AES power_supply after extended inactivity\") introduced wacom_aes_battery_handler() which is scheduled as a delayed work (aes_battery_work). In wacom_remove(), aes_battery_work is not canceled. Consequently, if the device is removed while aes_battery_work is still pending, then hard crashes or \"Oops: general protection fault...\" are experienced when wacom_aes_battery_handler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aes_battery_work was still pending at the time of hibernation. So, take care to cancel aes_battery_work in wacom_remove().", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38264", "url": "https://ubuntu.com/security/CVE-2025-38264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: sanitize request list handling Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38362", "url": "https://ubuntu.com/security/CVE-2025-38362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null pointer check for get_first_active_display() The function mod_hdcp_hdcp1_enable_encryption() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference in mod_hdcp_hdcp2_enable_encryption(). Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38354", "url": "https://ubuntu.com/security/CVE-2025-38354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/gpu: Fix crash when throttling GPU immediately during boot There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ... At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 (\"drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy\"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msm_devfreq_get_dev_status() will end up accessing GMU registers, causing the crash. Fix this by setting df->suspended correctly during initialization. Patchwork: https://patchwork.freedesktop.org/patch/650772/", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38363", "url": "https://ubuntu.com/security/CVE-2025-38363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix a possible null pointer dereference In tegra_crtc_reset(), new memory is allocated with kzalloc(), but no check is performed. Before calling __drm_atomic_helper_crtc_reset, state should be checked to prevent possible null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38239", "url": "https://ubuntu.com/security/CVE-2025-38239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38365", "url": "https://ubuntu.com/security/CVE-2025-38365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a race between renames and directory logging We have a race between a rename and directory inode logging that if it happens and we crash/power fail before the rename completes, the next time the filesystem is mounted, the log replay code will end up deleting the file that was being renamed. This is best explained following a step by step analysis of an interleaving of steps that lead into this situation. Consider the initial conditions: 1) We are at transaction N; 2) We have directories A and B created in a past transaction (< N); 3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as \"A/foo_link1\" and \"B/foo_link2\". Both hard links were persisted in a past transaction (< N); 4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as \"A/bar\". This file was also persisted in a past transaction (< N). The steps leading to a file loss are the following and for all of them we are under transaction N: 1) Link \"A/foo_link1\" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from \"A/bar\" to \"A/baz\", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry \"A/baz\" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name \"A/bar\" nor for the new name \"A/baz\" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree; 10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name \"A/bar\", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to \"A/bar\"). Since there's no other hard link for inode Y and the log replay code deletes the name \"A/bar\", the file is lost. The issue wouldn't happen if task B synced the log only after task A called btrfs_log_new_name(), which would update the log with the new name for inode Y (\"A/bar\"). Fix this by pinning the log root during renames before removing the old directory entry, and unpinning af ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38244", "url": "https://ubuntu.com/security/CVE-2025-38244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when reconnecting channels Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W ------------------------------------------------------ cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200 but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK *** 3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38245", "url": "https://ubuntu.com/security/CVE-2025-38245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister(). syzbot reported a warning below during atm_dev_register(). [0] Before creating a new device and procfs/sysfs for it, atm_dev_register() looks up a duplicated device by __atm_dev_lookup(). These operations are done under atm_dev_mutex. However, when removing a device in atm_dev_deregister(), it releases the mutex just after removing the device from the list that __atm_dev_lookup() iterates over. So, there will be a small race window where the device does not exist on the device list but procfs/sysfs are still not removed, triggering the splat. Let's hold the mutex until procfs/sysfs are removed in atm_dev_deregister(). [0]: proc_dir_entry 'atm/atmtcp:0' already registered WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377 Modules linked in: CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377 Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48 RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248 RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001 RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140 R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444 FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f38b3b74459 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459 RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005 RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b ", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38249", "url": "https://ubuntu.com/security/CVE-2025-38249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() In snd_usb_get_audioformat_uac3(), the length value returned from snd_usb_ctl_msg() is used directly for memory allocation without validation. This length is controlled by the USB device. The allocated buffer is cast to a uac3_cluster_header_descriptor and its fields are accessed without verifying that the buffer is large enough. If the device returns a smaller than expected length, this leads to an out-of-bounds read. Add a length check to ensure the buffer is large enough for uac3_cluster_header_descriptor.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38251", "url": "https://ubuntu.com/security/CVE-2025-38251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: prevent NULL deref in clip_push() Blamed commit missed that vcc_destroy_socket() calls clip_push() with a NULL skb. If clip_devs is NULL, clip_push() then crashes when reading skb->truesize.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38255", "url": "https://ubuntu.com/security/CVE-2025-38255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly() While testing null_blk with configfs, echo 0 > poll_queues will trigger following panic: BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__bitmap_or+0x48/0x70 Call Trace: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from kcalloc(), and later ZERO_SIZE_PTR will be deferenced. Fix the problem by checking numgrps first in group_cpus_evenly(), and return NULL directly if numgrps is zero. [yukuai3@huawei.com: also fix the non-SMP version]", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38257", "url": "https://ubuntu.com/security/CVE-2025-38257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Prevent overflow in size calculation for memdup_user() Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow. In this case the actual size of the allocated area and the value describing it won't be in sync leading to various types of unpredictable behaviour later. Use a proper memdup_array_user() helper which returns an error if an overflow is detected. Note that it is different from when nr_apqns is initially zero - that case is considered valid and should be handled in subsequent pkey_handler implementations. Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38258", "url": "https://ubuntu.com/security/CVE-2025-38258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write memcg_path_store() assigns a newly allocated memory buffer to filter->memcg_path, without deallocating the previously allocated and assigned memory buffer. As a result, users can leak kernel memory by continuously writing a data to memcg_path DAMOS sysfs file. Fix the leak by deallocating the previously set memory buffer.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38259", "url": "https://ubuntu.com/security/CVE-2025-38259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38230", "url": "https://ubuntu.com/security/CVE-2025-38230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: validate AG parameters in dbMount() to prevent crashes Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch corrupted metadata early and avoid undefined behavior in dbAllocAG. Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE: - agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0. - agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0. - agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8). UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9 shift exponent -335544310 is negative CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38260", "url": "https://ubuntu.com/security/CVE-2025-38260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: handle csum tree error with rescue=ibadroots correctly [BUG] There is syzbot based reproducer that can crash the kernel, with the following call trace: (With some debug output added) DEBUG: rescue=ibadroots parsed BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010) BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8 BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm BTRFS info (device loop0): using free-space-tree BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0 DEBUG: read tree root path failed for tree csum, ret=-5 BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0 BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0 process 'repro' launched './file2' with NULL argv: empty string added DEBUG: no csum root, idatacsums=0 ibadroots=134217728 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs] Call Trace: btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs] btrfs_submit_bbio+0x43e/0x1a80 [btrfs] submit_one_bio+0xde/0x160 [btrfs] btrfs_readahead+0x498/0x6a0 [btrfs] read_pages+0x1c3/0xb20 page_cache_ra_order+0x4b5/0xc20 filemap_get_pages+0x2d3/0x19e0 filemap_read+0x314/0xde0 __kernel_read+0x35b/0x900 bprm_execve+0x62e/0x1140 do_execveat_common.isra.0+0x3fc/0x520 __x64_sys_execveat+0xdc/0x130 do_syscall_64+0x54/0x1d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- [CAUSE] Firstly the fs has a corrupted csum tree root, thus to mount the fs we have to go \"ro,rescue=ibadroots\" mount option. Normally with that mount option, a bad csum tree root should set BTRFS_FS_STATE_NO_DATA_CSUMS flag, so that any future data read will ignore csum search. But in this particular case, we have the following call trace that caused NULL csum root, but not setting BTRFS_FS_STATE_NO_DATA_CSUMS: load_global_roots_objectid(): \t\tret = btrfs_search_slot(); \t\t/* Succeeded */ \t\tbtrfs_item_key_to_cpu() \t\tfound = true; \t\t/* We found the root item for csum tree. */ \t\troot = read_tree_root_path(); \t\tif (IS_ERR(root)) { \t\t\tif (!btrfs_test_opt(fs_info, IGNOREBADROOTS)) \t\t\t/* \t\t\t * Since we have rescue=ibadroots mount option, \t\t\t * @ret is still 0. \t\t\t */ \t\t\tbreak; \tif (!found || ret) { \t\t/* @found is true, @ret is 0, error handling for csum \t\t * tree is skipped. \t\t */ \t} This means we completely skipped to set BTRFS_FS_STATE_NO_DATA_CSUMS if the csum tree is corrupted, which results unexpected later csum lookup. [FIX] If read_tree_root_path() failed, always populate @ret to the error number. As at the end of the function, we need @ret to determine if we need to do the extra error handling for csum tree.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38262", "url": "https://ubuntu.com/security/CVE-2025-38262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: uartlite: register uart driver in init When two instances of uart devices are probing, a concurrency race can occur. If one thread calls uart_register_driver function, which first allocates and assigns memory to 'uart_state' member of uart_driver structure, the other instance can bypass uart driver registration and call ulite_assign. This calls uart_add_one_port, which expects the uart driver to be fully initialized. This leads to a kernel panic due to a null pointer dereference: [ 8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8 [ 8.156982] #PF: supervisor write access in kernel mode [ 8.156984] #PF: error_code(0x0002) - not-present page [ 8.156986] PGD 0 P4D 0 ... [ 8.180668] RIP: 0010:mutex_lock+0x19/0x30 [ 8.188624] Call Trace: [ 8.188629] ? __die_body.cold+0x1a/0x1f [ 8.195260] ? page_fault_oops+0x15c/0x290 [ 8.209183] ? __irq_resolve_mapping+0x47/0x80 [ 8.209187] ? exc_page_fault+0x64/0x140 [ 8.209190] ? asm_exc_page_fault+0x22/0x30 [ 8.209196] ? mutex_lock+0x19/0x30 [ 8.223116] uart_add_one_port+0x60/0x440 [ 8.223122] ? proc_tty_register_driver+0x43/0x50 [ 8.223126] ? tty_register_driver+0x1ca/0x1e0 [ 8.246250] ulite_probe+0x357/0x4b0 [uartlite] To prevent it, move uart driver registration in to init function. This will ensure that uart_driver is always registered when probe function is called.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38368", "url": "https://ubuntu.com/security/CVE-2025-38368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe() The returned value, pfsm->miscdev.name, from devm_kasprintf() could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 (\"ice: Fix some null pointer dereference issues in ice_ptp.c\"). This issue is found by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38436", "url": "https://ubuntu.com/security/CVE-2025-38436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/scheduler: signal scheduled fence when kill job When an entity from application B is killed, drm_sched_entity_kill() removes all jobs belonging to that entity through drm_sched_entity_kill_jobs_work(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared. This leads to application A hanging indefinitely while waiting for a dependency that will never be resolved. Fix this issue by ensuring that scheduled fences are properly signaled when an entity is killed, allowing dependent applications to continue execution.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38263", "url": "https://ubuntu.com/security/CVE-2025-38263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix NULL pointer in cache_set_flush() 1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc(). 2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set(). 3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue(\"bcache_gc\", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 } (1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885). (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return. (3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL. LINE#1624 - LINE#1665 is some codes about function of cache_set_flush(). As (1), in LINE#1885 call bch_cache_set_unregister() ---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 } (4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below: [ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory [ 846.713242] bcache: register_bcache() error : failed to register device [ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered [ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8 [ 846.714790] PGD 0 P4D 0 [ 846.715129] Oops: 0000 [#1] SMP PTI [ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1 [ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018 [ 846.716451] Workqueue: events cache_set_flush [bcache] [ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache] [ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38369", "url": "https://ubuntu.com/security/CVE-2025-38369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated. This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point. In this case, when the user driver detaches, the WQ is destroyed but it still calls destroy_workqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-22128", "url": "https://ubuntu.com/security/CVE-2025-22128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath12k_pci_msi_alloc(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This may end up with a warning from the IRQ core that is expecting the affinity hint to be cleared before freeing the IRQ: kernel/irq/manage.c: \t/* make sure affinity_hint is cleaned up */ \tif (WARN_ON_ONCE(desc->affinity_hint)) \t\tdesc->affinity_hint = NULL; So to fix this issue, clear the IRQ affinity hint before calling ath12k_pci_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38333", "url": "https://ubuntu.com/security/CVE-2025-38333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to bail out in get_new_segment() ------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20 get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38210", "url": "https://ubuntu.com/security/CVE-2025-38210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs-tsm-report: Fix NULL dereference of tsm_ops Unlike sysfs, the lifetime of configfs objects is controlled by userspace. There is no mechanism for the kernel to find and delete all created config-items. Instead, the configfs-tsm-report mechanism has an expectation that tsm_unregister() can happen at any time and cause established config-item access to start failing. That expectation is not fully satisfied. While tsm_report_read(), tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail if tsm_ops have been unregistered, tsm_report_privlevel_store() tsm_report_provider_show() fail to check for ops registration. Add the missing checks for tsm_ops having been removed. Now, in supporting the ability for tsm_unregister() to always succeed, it leaves the problem of what to do with lingering config-items. The expectation is that the admin that arranges for the ->remove() (unbind) of the ${tsm_arch}-guest driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bind) of the ${tsm_arch}-guest driver fails. This allows for emergency shutdown / revocation of attestation interfaces, and requires coordinated restart.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38232", "url": "https://ubuntu.com/security/CVE-2025-38232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38320", "url": "https://ubuntu.com/security/CVE-2025-38320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] __se_sys_clone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] dup_task_struct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before: commit d93a855c31b7 (\"s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()\") As described in that commit, regs_get_kernel_stack_nth() has confirmed that `addr` is on the stack, so reading the value at `*addr` should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case. [will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38424", "url": "https://ubuntu.com/security/CVE-2025-38424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Fix sample vs do_exit() Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons. Flip this order by moving up where we stop perf in do_exit(). Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER to abort when the current task does not have an mm (exit_mm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38321", "url": "https://ubuntu.com/security/CVE-2025-38321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: Log an error when close_all_cached_dirs fails Under low-memory conditions, close_all_cached_dirs() can't move the dentries to a separate list to dput() them once the locks are dropped. This will result in a \"Dentry still in use\" error, so add an error message that makes it clear this is what happened: [ 495.281119] CIFS: VFS: \\\\otters.example.com\\share Out of memory while dropping dentries [ 495.281595] ------------[ cut here ]------------ [ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs] [ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0 Also, bail out of looping through all tcons as soon as a single allocation fails, since we're already in trouble, and kmalloc() attempts for subseqeuent tcons are likely to fail just like the first one did.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38180", "url": "https://ubuntu.com/security/CVE-2025-38180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: fix /proc/net/atm/lec handling /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls without prior dev_hold(), leading to imbalance and UAF.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38323", "url": "https://ubuntu.com/security/CVE-2025-38323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: add lec_mutex syzbot found its way in net/atm/lec.c, and found an error path in lecd_attach() could leave a dangling pointer in dev_lec[]. Add a mutex to protect dev_lecp[] uses from lecd_attach(), lec_vcc_attach() and lec_mcast_attach(). Following patch will use this mutex for /proc/net/atm/lec. BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline] BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142 CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xcd/0x680 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 lecd_attach net/atm/lec.c:751 [inline] lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4328 [inline] __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015 alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711 lecd_attach net/atm/lec.c:737 [inline] lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x2b4/0x4d0 mm/slub.c:4842 free_netdev+0x6c5/0x910 net/core/dev.c:11892 lecd_attach net/atm/lec.c:744 [inline] lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38181", "url": "https://ubuntu.com/security/CVE-2025-38181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: calipso: Fix null-ptr-deref in calipso_req_{set,del}attr(). syzkaller reported a null-ptr-deref in sock_omalloc() while allocating a CALIPSO option. [0] The NULL is of struct sock, which was fetched by sk_to_full_sk() in calipso_req_setattr(). Since commit a1a5344ddbe8 (\"tcp: avoid two atomic ops for syncookies\"), reqsk->rsk_listener could be NULL when SYN Cookie is returned to its client, as hinted by the leading SYN Cookie log. Here are 3 options to fix the bug: 1) Return 0 in calipso_req_setattr() 2) Return an error in calipso_req_setattr() 3) Alaways set rsk_listener 1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie for CALIPSO. 3) is also no go as there have been many efforts to reduce atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35 (\"tcp/dccp: do not touch listener sk_refcnt under synflood\"). As of the blamed commit, SYN Cookie already did not need refcounting, and no one has stumbled on the bug for 9 years, so no CALIPSO user will care about SYN Cookie. Let's return an error in calipso_req_setattr() and calipso_req_delattr() in the SYN Cookie case. This can be reproduced by [1] on Fedora and now connect() of nc times out. [0]: TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806 Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b RSP: 0018:ffff88811af89038 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400 RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030 RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000 R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050 FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551 security_inet_conn_request+0x50/0xa0 security/security.c:4945 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:469 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netf ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38182", "url": "https://ubuntu.com/security/CVE-2025-38182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: santizize the arguments from userspace when adding a device Sanity check the values for queue depth and number of queues we get from userspace when adding a device.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38183", "url": "https://ubuntu.com/security/CVE-2025-38183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get() Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8). This seems correct and aligns with the PTP interrupt status register (PTP_INT_STS) specifications. However, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index: lan743x_ptp_io_event_clock_get(..., u8 channel,...) { ... /* Update Local timestamp */ extts = &ptp->extts[channel]; extts->ts.tv_sec = sec; ... } To avoid an out-of-bounds write and utilize all the supported GPIO inputs, set LAN743X_PTP_N_EXTTS to 8. Detected using the static analysis tool - Svace.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38184", "url": "https://ubuntu.com/security/CVE-2025-38184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer , priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0 the ub was in fact a struct dev. when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it. fix this by checking media_id.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38185", "url": "https://ubuntu.com/security/CVE-2025-38185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Free invalid length skb in atmtcp_c_send(). syzbot reported the splat below. [0] vcc_sendmsg() copies data passed from userspace to skb and passes it to vcc->dev->ops->send(). atmtcp_c_send() accesses skb->data as struct atmtcp_hdr after checking if skb->len is 0, but it's not enough. Also, when skb->len == 0, skb and sk (vcc) were leaked because dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing to revert atm_account_tx() in vcc_sendmsg(), which is expected to be done in atm_pop_raw(). Let's properly free skb with an invalid length in atmtcp_c_send(). [0]: BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38324", "url": "https://ubuntu.com/security/CVE-2025-38324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu(). As syzbot reported [0], mpls_route_input_rcu() can be called from mpls_getroute(), where is under RTNL. net->mpls.platform_label is only updated under RTNL. Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to silence the splat. [0]: WARNING: suspicious RCU usage 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ---------------------------- net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961 stack backtrace: CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 ", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38420", "url": "https://ubuntu.com/security/CVE-2025-38420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: do not ping device which has failed to load firmware Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38326", "url": "https://ubuntu.com/security/CVE-2025-38326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: clean device rq_list in aoedev_downdev() An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue().", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38089", "url": "https://ubuntu.com/security/CVE-2025-38089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: handle SVC_GARBAGE during svc auth processing as auth error tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble. The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR. Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash.", "cve_priority": "medium", "cve_public_date": "2025-06-30 08:15:00 UTC" }, { "cve": "CVE-2025-38084", "url": "https://ubuntu.com/security/CVE-2025-38084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 (\"hugetlb: unshare some PMDs when splitting VMAs\"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2]", "cve_priority": "medium", "cve_public_date": "2025-06-28 08:15:00 UTC" }, { "cve": "CVE-2025-38190", "url": "https://ubuntu.com/security/CVE-2025-38190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: Revert atm_account_tx() if copy_from_iter_full() fails. In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by atm_account_tx(). It is expected to be reverted by atm_pop_raw() later called by vcc->dev->ops->send(vcc, skb). However, vcc_sendmsg() misses the same revert when copy_from_iter_full() fails, and then we will leak a socket. Let's factorise the revert part as atm_return_tx() and call it in the failure path. Note that the corresponding sk_wmem_alloc operation can be found in alloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38191", "url": "https://ubuntu.com/security/CVE-2025-38191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference in destroy_previous_session If client set ->PreviousSessionId on kerberos session setup stage, NULL pointer dereference error will happen. Since sess->user is not set yet, It can pass the user argument as NULL to destroy_previous_session. sess->user will be set in ksmbd_krb5_authenticate(). So this patch move calling destroy_previous_session() after ksmbd_krb5_authenticate().", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38192", "url": "https://ubuntu.com/security/CVE-2025-38192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38193", "url": "https://ubuntu.com/security/CVE-2025-38193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: reject invalid perturb period Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch. We want to make sure ctl->perturb_period * HZ will not overflow and is positive. tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38328", "url": "https://ubuntu.com/security/CVE-2025-38328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jffs2: check jffs2_prealloc_raw_node_refs() result in few other places Fuzzing hit another invalid pointer dereference due to the lack of checking whether jffs2_prealloc_raw_node_refs() completed successfully. Subsequent logic implies that the node refs have been allocated. Handle that. The code is ready for propagating the error upwards. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600 Call Trace: jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline] jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497 call_write_iter include/linux/fs.h:2039 [inline] do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740 do_iter_write+0x18c/0x710 fs/read_write.c:866 vfs_writev+0x1db/0x6a0 fs/read_write.c:939 do_pwritev fs/read_write.c:1036 [inline] __do_sys_pwritev fs/read_write.c:1083 [inline] __se_sys_pwritev fs/read_write.c:1078 [inline] __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38194", "url": "https://ubuntu.com/security/CVE-2025-38194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jffs2: check that raw node were preallocated before writing summary Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't check return value of jffs2_prealloc_raw_node_refs and simply lets any error propagate into jffs2_sum_write_data, which eventually calls jffs2_link_node_ref in order to link the summary to an expectedly allocated node. kernel BUG at fs/jffs2/nodelist.c:592! invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592 Call Trace: jffs2_sum_write_data fs/jffs2/summary.c:841 [inline] jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005 call_write_iter include/linux/fs.h:2265 [inline] do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10c/0x170 fs/splice.c:950 splice_direct_to_actor+0x337/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fix this issue by checking return value of jffs2_prealloc_raw_node_refs before calling jffs2_sum_write_data. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38090", "url": "https://ubuntu.com/security/CVE-2025-38090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace.", "cve_priority": "medium", "cve_public_date": "2025-06-30 08:15:00 UTC" }, { "cve": "CVE-2025-38197", "url": "https://ubuntu.com/security/CVE-2025-38197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell_rbu: Fix list usage Pass the correct list head to list_for_each_entry*() when looping through the packet list. Without this patch, reading the packet data via sysfs will show the data incorrectly (because it starts at the wrong packet), and clearing the packet list will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38198", "url": "https://ubuntu.com/security/CVE-2025-38198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Make sure modelist not set on unregistered console It looks like attempting to write to the \"store_modes\" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing \"info\" pointers, so error handling should kick in correctly.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38331", "url": "https://ubuntu.com/security/CVE-2025-38331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Use TOE/TSO on all TCP It is desireable to push the hardware accelerator to also process non-segmented TCP frames: we pass the skb->len to the \"TOE/TSO\" offloader and it will handle them. Without this quirk the driver becomes unstable and lock up and and crash. I do not know exactly why, but it is probably due to the TOE (TCP offload engine) feature that is coupled with the segmentation feature - it is not possible to turn one part off and not the other, either both TOE and TSO are active, or neither of them. Not having the TOE part active seems detrimental, as if that hardware feature is not really supposed to be turned off. The datasheet says: \"Based on packet parsing and TCP connection/NAT table lookup results, the NetEngine puts the packets belonging to the same TCP connection to the same queue for the software to process. The NetEngine puts incoming packets to the buffer or series of buffers for a jumbo packet. With this hardware acceleration, IP/TCP header parsing, checksum validation and connection lookup are offloaded from the software processing.\" After numerous tests with the hardware locking up after something between minutes and hours depending on load using iperf3 I have concluded this is necessary to stabilize the hardware.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38200", "url": "https://ubuntu.com/security/CVE-2025-38200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix MMIO write access to an invalid page in i40e_clear_hw When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38332", "url": "https://ubuntu.com/security/CVE-2025-38332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Use memcpy() for BIOS version The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38342", "url": "https://ubuntu.com/security/CVE-2025-38342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Correct a OOB check in software_node_get_reference_args() software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38334", "url": "https://ubuntu.com/security/CVE-2025-38334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Prevent attempts to reclaim poisoned pages TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode operations including \"EWB\" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a \"TBD\" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply. This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38425", "url": "https://ubuntu.com/security/CVE-2025-38425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: check msg length in SMBUS block read For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38343", "url": "https://ubuntu.com/security/CVE-2025-38343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: drop fragments with multicast or broadcast RA IEEE 802.11 fragmentation can only be applied to unicast frames. Therefore, drop fragments with multicast or broadcast RA. This patch addresses vulnerabilities such as CVE-2020-26145.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38202", "url": "https://ubuntu.com/security/CVE-2025-38202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem() bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38422", "url": "https://ubuntu.com/security/CVE-2025-38422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38344", "url": "https://ubuntu.com/security/CVE-2025-38344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi parse and parseext cache leaks ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5 I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38345", "url": "https://ubuntu.com/security/CVE-2025-38345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi operand cache leak in dswstate.c ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38085", "url": "https://ubuntu.com/security/CVE-2025-38085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.", "cve_priority": "medium", "cve_public_date": "2025-06-28 08:15:00 UTC" }, { "cve": "CVE-2025-38208", "url": "https://ubuntu.com/security/CVE-2025-38208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: add NULL check in automount_fullpath page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38418", "url": "https://ubuntu.com/security/CVE-2025-38418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Release rproc->clean_table after rproc_attach() fails When rproc->state = RPROC_DETACHED is attached to remote processor through rproc_attach(), if rproc_handle_resources() returns failure, then the clean table should be released, otherwise the following memory leak will occur. unreferenced object 0xffff000086a99800 (size 1024): comm \"kworker/u12:3\", pid 59, jiffies 4294893670 (age 121.140s) hex dump (first 32 bytes): 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............ 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............ backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16):", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38419", "url": "https://ubuntu.com/security/CVE-2025-38419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach() When rproc->state = RPROC_DETACHED and rproc_attach() is used to attach to the remote processor, if rproc_handle_resources() returns a failure, the resources allocated by imx_rproc_prepare() should be released, otherwise the following memory leak will occur. Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cleanup() is able to deal with empty lists so it is better to fix the \"goto\" statements in rproc_attach(). replace the \"unprepare_device\" goto statement with \"clean_up_resources\" and get rid of the \"unprepare_device\" label. unreferenced object 0xffff0000861c5d00 (size 128): comm \"kworker/u12:3\", pid 59, jiffies 4294893509 (age 149.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38427", "url": "https://ubuntu.com/security/CVE-2025-38427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: video: screen_info: Relocate framebuffers behind PCI bridges Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory. Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screen_info refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself. Commit 78aa89d1dfba (\"firmware/sysfb: Update screen_info for relocated EFI framebuffers\") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v3: - Only use struct pci_bus_region for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38086", "url": "https://ubuntu.com/security/CVE-2025-38086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ch9200: fix uninitialised access during mii_nway_restart In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called \"buff\", which is initialised with control_read(). However \"buff\" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of \"err == size\" is not met, then \"buff\" remains uninitialised. Once this happens the uninitialised \"buff\" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of \"buff\". To fix this we should check the return value of control_read() and return early on error.", "cve_priority": "medium", "cve_public_date": "2025-06-28 08:15:00 UTC" }, { "cve": "CVE-2025-38346", "url": "https://ubuntu.com/security/CVE-2025-38346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix UAF when lookup kallsym after ftrace disabled The following issue happens with a buggy module: BUG: unable to handle page fault for address: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The above issue may happen as follows: (1) Add kprobe tracepoint; (2) insmod test.ko; (3) Module triggers ftrace disabled; (4) rmmod test.ko; (5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed; ftrace_mod_get_kallsym() ... strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); ... The problem is when a module triggers an issue with ftrace and sets ftrace_disable. The ftrace_disable is set when an anomaly is discovered and to prevent any more damage, ftrace stops all text modification. The issue that happened was that the ftrace_disable stops more than just the text modification. When a module is loaded, its init functions can also be traced. Because kallsyms deletes the init functions after a module has loaded, ftrace saves them when the module is loaded and function tracing is enabled. This allows the output of the function trace to show the init function names instead of just their raw memory addresses. When a module is removed, ftrace_release_mod() is called, and if ftrace_disable is set, it just returns without doing anything more. The problem here is that it leaves the mod_list still around and if kallsyms is called, it will call into this code and access the module memory that has already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); Where the \"mod\" no longer exists and triggers a UAF bug.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38211", "url": "https://ubuntu.com/security/CVE-2025-38211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction The commit 59c68ac31e15 (\"iw_cm: free cm_id resources on the last deref\") simplified cm_id resource management by freeing cm_id once all references to the cm_id were removed. The references are removed either upon completion of iw_cm event handlers or when the application destroys the cm_id. This commit introduced the use-after-free condition where cm_id_private object could still be in use by event handler works during the destruction of cm_id. The commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\") addressed this use-after- free by flushing all pending works at the cm_id destruction. However, still another use-after-free possibility remained. It happens with the work objects allocated for each cm_id_priv within alloc_work_entries() during cm_id creation, and subsequently freed in dealloc_work_entries() once all references to the cm_id are removed. If the cm_id's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver. To avoid the use-after-free of cm_id_private work objects, ensure that the last reference to the cm_id is decremented not in the event handler works, but in the cm_id destruction context. For that purpose, mo ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38212", "url": "https://ubuntu.com/security/CVE-2025-38212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: fix to protect IPCS lookups using RCU syzbot reported that it discovered a use-after-free vulnerability, [0] [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/ idr_for_each() is protected by rwsem, but this is not enough. If it is not protected by RCU read-critical region, when idr_for_each() calls radix_tree_node_free() through call_rcu() to free the radix_tree_node structure, the node will be freed immediately, and when reading the next node in radix_tree_for_each_slot(), the already freed memory may be read. Therefore, we need to add code to make sure that idr_for_each() is protected within the RCU read-critical region when we call it in shm_destroy_orphaned().", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38214", "url": "https://ubuntu.com/security/CVE-2025-38214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38215", "url": "https://ubuntu.com/security/CVE-2025-38215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in do_register_framebuffer() fails to allocate memory for fb_videomode, it will later lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ Even though fbcon_init() checks beforehand if fb_match_mode() in var_to_display() fails, it can not prevent the panic because fbcon_init() does not return error code. Considering this and the comment in the code about fb_match_mode() returning NULL - \"This should not happen\" - it is better to prevent registering the fb_info if its mode was not set successfully. Also move fb_add_videomode() closer to the beginning of do_register_framebuffer() to avoid having to do the cleanup on fail. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38087", "url": "https://ubuntu.com/security/CVE-2025-38087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.", "cve_priority": "medium", "cve_public_date": "2025-06-30 08:15:00 UTC" }, { "cve": "CVE-2025-38416", "url": "https://ubuntu.com/security/CVE-2025-38416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nci: uart: Set tty->disc_data only in success path Setting tty->disc_data before opening the NCI device means we need to clean it up on error paths. This also opens some short window if device starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded (broken hardware?). Close the window by exposing tty->disc_data only on the success path, when opening of the NCI device and try_module_get() succeeds. The code differs in error path in one aspect: tty->disc_data won't be ever assigned thus NULL-ified. This however should not be relevant difference, because of \"tty->disc_data=NULL\" in nci_uart_tty_open().", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38217", "url": "https://ubuntu.com/security/CVE-2025-38217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (ftsteutates) Fix TOCTOU race in fts_read() In the fts_read() function, when handling hwmon_pwm_auto_channels_temp, the code accesses the shared variable data->fan_source[channel] twice without holding any locks. It is first checked against FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again when used as an argument to the BIT() macro. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Another thread executing fts_update_device() can modify the value of data->fan_source[channel] between the check and its use. If the value is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the BIT() macro will be called with a large shift value (BIT(255)). A bit shift by a value greater than or equal to the type width is undefined behavior and can lead to a crash or incorrect values being returned to userspace. Fix this by reading data->fan_source[channel] into a local variable once, eliminating the race condition. Additionally, add a bounds check to ensure the value is less than BITS_PER_LONG before passing it to the BIT() macro, making the code more robust against undefined behavior. This possible bug was found by an experimental static analysis tool developed by our team.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38218", "url": "https://ubuntu.com/security/CVE-2025-38218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sit_bitmap_size w/ below testcase, resize will generate a corrupted image which contains inconsistent metadata, so when mounting such image, it will trigger kernel panic: touch img truncate -s $((512*1024*1024*1024)) img mkfs.f2fs -f img $((256*1024*1024)) resize.f2fs -s -i img -t $((1024*1024*1024)) mount img /mnt/f2fs ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.h:863! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490 Call Trace: f2fs_build_segment_manager+0x11c3/0x2600 f2fs_fill_super+0xe97/0x2840 mount_bdev+0xf4/0x140 legacy_get_tree+0x2b/0x50 vfs_get_tree+0x29/0xd0 path_mount+0x487/0xaf0 __x64_sys_mount+0x116/0x150 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdbfde1bcfe The reaseon is: sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt is 4762, build_sit_entries() -> current_sit_addr() tries to access out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on(). Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38219", "url": "https://ubuntu.com/security/CVE-2025-38219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: prevent kernel warning due to negative i_nlink from corrupted image WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Modules linked in: CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted 6.14.0-12627-g94d471a4f428 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90 <0f> 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6 ff RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005 RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000 R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0 FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0 Call Trace: f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline] f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845 f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909 f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581 vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544 do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608 __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline] __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline] __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652 do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb3d092324b Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0 RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0 R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0 R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001 ", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38347", "url": "https://ubuntu.com/security/CVE-2025-38347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on ino and xnid syzbot reported a f2fs bug as below: INFO: task syz-executor140:5308 blocked for more than 143 seconds. Not tainted 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz-executor140 state:D stack:24016 pid:5308 tgid:5308 ppid:5306 task_flags:0x400140 flags:0x00000006 Call Trace: context_switch kernel/sched/core.c:5378 [inline] __schedule+0x190e/0x4c90 kernel/sched/core.c:6765 __schedule_loop kernel/sched/core.c:6842 [inline] schedule+0x14b/0x320 kernel/sched/core.c:6857 io_schedule+0x8d/0x110 kernel/sched/core.c:7690 folio_wait_bit_common+0x839/0xee0 mm/filemap.c:1317 __folio_lock mm/filemap.c:1664 [inline] folio_lock include/linux/pagemap.h:1163 [inline] __filemap_get_folio+0x147/0xb40 mm/filemap.c:1917 pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87 find_get_page_flags include/linux/pagemap.h:842 [inline] f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776 __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463 read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306 lookup_all_xattrs fs/f2fs/xattr.c:355 [inline] f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533 __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179 f2fs_acl_create fs/f2fs/acl.c:375 [inline] f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418 f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539 f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666 f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765 f2fs_do_add_link+0x28c/0x3a0 fs/f2fs/dir.c:808 f2fs_add_link fs/f2fs/f2fs.h:3616 [inline] f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766 vfs_mknod+0x36d/0x3b0 fs/namei.c:4191 unix_bind_bsd net/unix/af_unix.c:1286 [inline] unix_bind+0x563/0xe30 net/unix/af_unix.c:1379 __sys_bind_socket net/socket.c:1817 [inline] __sys_bind+0x1e4/0x290 net/socket.c:1848 __do_sys_bind net/socket.c:1853 [inline] __se_sys_bind net/socket.c:1851 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1851 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Let's dump and check metadata of corrupted inode, it shows its xattr_nid is the same to its i_ino. dump.f2fs -i 3 chaseyu.img.raw i_xattr_nid [0x 3 : 3] So that, during mknod in the corrupted directory, it tries to get and lock inode page twice, result in deadlock. - f2fs_mknod - f2fs_add_inline_entry - f2fs_get_inode_page --- lock dir's inode page - f2fs_init_acl - f2fs_acl_create(dir,..) - __f2fs_get_acl - f2fs_getxattr - lookup_all_xattrs - __get_node_page --- try to lock dir's inode page In order to fix this, let's add sanity check on ino and xnid.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38428", "url": "https://ubuntu.com/security/CVE-2025-38428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - check record size in ims_pcu_flash_firmware() The \"len\" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the \"len\" is too large it could result in memory corruption when we do \"memcpy(fragment->data, rec->data, len);\"", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38220", "url": "https://ubuntu.com/security/CVE-2025-38220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: only dirty folios when data journaling regular files fstest generic/388 occasionally reproduces a crash that looks as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: ext4_block_zero_page_range+0x30c/0x380 [ext4] ext4_truncate+0x436/0x440 [ext4] ext4_process_orphan+0x5d/0x110 [ext4] ext4_orphan_cleanup+0x124/0x4f0 [ext4] ext4_fill_super+0x262d/0x3110 [ext4] get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x26/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4ed/0x6b0 do_syscall_64+0x82/0x170 ... This occurs when processing a symlink inode from the orphan list. The partial block zeroing code in the truncate path calls ext4_dirty_journalled_data() -> folio_mark_dirty(). The latter calls mapping->a_ops->dirty_folio(), but symlink inodes are not assigned an a_ops vector in ext4, hence the crash. To avoid this problem, update the ext4_dirty_journalled_data() helper to only mark the folio dirty on regular files (for which a_ops is assigned). This also matches the journaling logic in the ext4_symlink() creation path, where ext4_handle_dirty_metadata() is called directly.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38222", "url": "https://ubuntu.com/security/CVE-2025-38222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: inline: fix len overflow in ext4_prepare_inline_data When running the following code on an ext4 filesystem with inline_data feature enabled, it will lead to the bug below. fd = open(\"file1\", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, \"a\", 1, (1UL << 40) + 5UL); That happens because write_begin will succeed as when ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len will be truncated, leading to ext4_prepare_inline_data parameter to be 6 instead of 0x10000000006. Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); at ext4_write_inline_data. Fix it by using a loff_t type for the len parameter in ext4_prepare_inline_data instead of an unsigned int. [ 44.545164] ------------[ cut here ]------------ [ 44.545530] kernel BUG at fs/ext4/inline.c:240! [ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb [ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100 [ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49 [ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216 [ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006 [ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738 [ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000 [ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738 [ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000 [ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0 [ 44.546523] PKRU: 55555554 [ 44.546523] Call Trace: [ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0 [ 44.546523] generic_perform_write+0x17e/0x270 [ 44.546523] ext4_buffered_write_iter+0xc8/0x170 [ 44.546523] vfs_write+0x2be/0x3e0 [ 44.546523] __x64_sys_pwrite64+0x6d/0xc0 [ 44.546523] do_syscall_64+0x6a/0xf0 [ 44.546523] ? __wake_up+0x89/0xb0 [ 44.546523] ? xas_find+0x72/0x1c0 [ 44.546523] ? next_uptodate_folio+0x317/0x330 [ 44.546523] ? set_pte_range+0x1a6/0x270 [ 44.546523] ? filemap_map_pages+0x6ee/0x840 [ 44.546523] ? ext4_setattr+0x2fa/0x750 [ 44.546523] ? do_pte_missing+0x128/0xf70 [ 44.546523] ? security_inode_post_setattr+0x3e/0xd0 [ 44.546523] ? ___pte_offset_map+0x19/0x100 [ 44.546523] ? handle_mm_fault+0x721/0xa10 [ 44.546523] ? do_user_addr_fault+0x197/0x730 [ 44.546523] ? do_syscall_64+0x76/0xf0 [ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60 [ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90 [ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 44.546523] RIP: 0033:0x7f42999c6687 [ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff [ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012 [ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687 [ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003 [ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000 [ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38336", "url": "https://ubuntu.com/security/CVE-2025-38336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330 The controller has a hardware bug that can hard hang the system when doing ATAPI DMAs without any trace of what happened. Depending on the device attached, it can also prevent the system from booting. In this case, the system hangs when reading the ATIP from optical media with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, running at UDMA/33. The issue can be reproduced by running the same command with a cygwin build of cdrecord on WinXP, although it requires more attempts to cause it. The hang in that case is also resolved by forcing PIO. It doesn't appear that VIA has produced any drivers for that OS, thus no known workaround exists. HDDs attached to the controller do not suffer from any DMA issues.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38429", "url": "https://ubuntu.com/security/CVE-2025-38429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Update read pointer only after buffer is written Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated before the buffer is written, potentially causing race conditions where the host sees an updated read pointer before the buffer is actually written. Updating rd_offset prematurely can lead to the host accessing an uninitialized or incomplete element, resulting in data corruption. Invoke the buffer write before updating rd_offset to ensure the element is fully written before signaling its availability.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38225", "url": "https://ubuntu.com/security/CVE-2025-38225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Cleanup after an allocation error When allocation failures are not cleaned up by the driver, further allocation errors will be false-positives, which will cause buffers to remain uninitialized and cause NULL pointer dereferences. Ensure proper cleanup of failed allocations to prevent these issues.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38226", "url": "https://ubuntu.com/security/CVE-2025-38226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: Change the siize of the composing syzkaller found a bug: BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304 CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline] vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629 vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The composition size cannot be larger than the size of fmt_cap_rect. So execute v4l2_rect_map_inside() even if has_compose_cap == 0.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38229", "url": "https://ubuntu.com/security/CVE-2025-38229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cxusb: no longer judge rbuf when the write fails syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38337", "url": "https://ubuntu.com/security/CVE-2025-38337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() Since handle->h_transaction may be a NULL pointer, so we should change it to call is_handle_aborted(handle) first before dereferencing it. And the following data-race was reported in my fuzzer: ================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ================================================================== This issue is caused by missing data-race annotation for jh->b_modified. Therefore, the missing annotation needs to be added.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38338", "url": "https://ubuntu.com/security/CVE-2025-38338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which never happens because nobody is really holding the folio lock.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38231", "url": "https://ubuntu.com/security/CVE-2025-38231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Initialize ssc before laundromat_work to prevent NULL dereference In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through nfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized, this can cause NULL pointer dereference. Normally the delayed start of laundromat_work allows sufficient time for nfsd_ssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4_state_start_net -> nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done -> cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), the delayed work may start before nfsd_ssc initialization finishes. Fix this by moving nfsd_ssc initialization before starting laundromat_work.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38430", "url": "https://ubuntu.com/security/CVE-2025-38430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request If the request being processed is not a v4 compound request, then examining the cstate can have undefined results. This patch adds a check that the rpc procedure being executed (rq_procinfo) is the NFSPROC4_COMPOUND procedure.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38348", "url": "https://ubuntu.com/security/CVE-2025-38348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback() Robert Morris reported: |If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun. This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the \"firmware\" altered the value and no longer copies them. The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38101", "url": "https://ubuntu.com/security/CVE-2025-38101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set() Enlarge the critical section in ring_buffer_subbuf_order_set() to ensure that error handling takes place with per-buffer mutex held, thus preventing list corruption and other concurrency-related issues.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38269", "url": "https://ubuntu.com/security/CVE-2025-38269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: exit after state insertion failure at btrfs_convert_extent_bit() If insert_state() state failed it returns an error pointer and we call extent_io_tree_panic() which will trigger a BUG() call. However if CONFIG_BUG is disabled, which is an uncommon and exotic scenario, then we fallthrough and call cache_state() which will dereference the error pointer, resulting in an invalid memory access. So jump to the 'out' label after calling extent_io_tree_panic(), it also makes the code more clear besides dealing with the exotic scenario where CONFIG_BUG is disabled.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38303", "url": "https://ubuntu.com/security/CVE-2025-38303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38414", "url": "https://ubuntu.com/security/CVE-2025-38414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850 GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms. Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38125", "url": "https://ubuntu.com/security/CVE-2025-38125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38129", "url": "https://ubuntu.com/security/CVE-2025-38129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: page_pool: Fix use-after-free in page_pool_recycle_in_ring syzbot reported a uaf in page_pool_recycle_in_ring: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943 CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline] root cause is: page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool \t\t\t\tpage_pool_release \t\t\t\t page_pool_scrub \t\t\t\t page_pool_empty_ring \t\t\t\t ptr_ring_consume \t\t\t\t page_pool_return_page //release all page \t\t\t\t __page_pool_destroy \t\t\t\t free_percpu(pool->recycle_stats); \t\t\t\t free(pool) //free spin_unlock(&r->producer_lock); //pool->ring uaf read recycle_stat_inc(pool, ring); page_pool can be free while page pool recycle the last page in ring. Add producer-lock barrier to page_pool_release to prevent the page pool from being free before all pages have been recycled. recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38156", "url": "https://ubuntu.com/security/CVE-2025-38156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init()", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38162", "url": "https://ubuntu.com/security/CVE-2025-38162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: prevent overflow in lookup table allocation When calculating the lookup table size, ensure the following multiplication does not overflow: - desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case. - NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field. Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this. While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38292", "url": "https://ubuntu.com/security/CVE-2025-38292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix invalid access to memory In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean is_continuation is part of rxcb. Currently, after freeing the skb, the rxcb->is_continuation accessed again which is wrong since the memory is already freed. This might lead use-after-free error. Hence, fix by locally defining bool is_continuation from rxcb, so that after freeing skb, is_continuation can be used. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38164", "url": "https://ubuntu.com/security/CVE-2025-38164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: zone: fix to avoid inconsistence in between SIT and SSA w/ below testcase, it will cause inconsistence in between SIT and SSA. create_null_blk 512 2 1024 1024 mkfs.f2fs -m /dev/nullb0 mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/file f2fs_io pinfile set /mnt/f2fs/file fallocate -l 4GiB /mnt/f2fs/file F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G O 6.13.0-rc1 #84 Tainted: [O]=OOT_MODULE Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: dump_stack_lvl+0xb3/0xd0 dump_stack+0x14/0x20 f2fs_handle_critical_error+0x18c/0x220 [f2fs] f2fs_stop_checkpoint+0x38/0x50 [f2fs] do_garbage_collect+0x674/0x6e0 [f2fs] f2fs_gc_range+0x12b/0x230 [f2fs] f2fs_allocate_pinning_section+0x5c/0x150 [f2fs] f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs] f2fs_fallocate+0x3c3/0x410 [f2fs] vfs_fallocate+0x15f/0x4b0 __x64_sys_fallocate+0x4a/0x80 x64_sys_call+0x15e8/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f9dba5197ca F2FS-fs (nullb0): Stopped filesystem due to reason: 4 The reason is f2fs_gc_range() may try to migrate block in curseg, however, its SSA block is not uptodate due to the last summary block data is still in cache of curseg. In this patch, we add a condition in f2fs_gc_range() to check whether section is opened or not, and skip block migration for opened section.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38169", "url": "https://ubuntu.com/security/CVE-2025-38169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP On system with SME, a thread's kernel FPSIMD state may be erroneously clobbered during a context switch immediately after that state is restored. Systems without SME are unaffected. If the CPU happens to be in streaming SVE mode before a context switch to a thread with kernel FPSIMD state, fpsimd_thread_switch() will restore the kernel FPSIMD state using fpsimd_load_kernel_state() while the CPU is still in streaming SVE mode. When fpsimd_thread_switch() subsequently calls fpsimd_flush_cpu_state(), this will execute an SMSTOP, causing an exit from streaming SVE mode. The exit from streaming SVE mode will cause the hardware to reset a number of FPSIMD/SVE/SME registers, clobbering the FPSIMD state. Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel FPSIMD state.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38299", "url": "https://ubuntu.com/security/CVE-2025-38299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY() ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(), in the case the codec dai_name will be null. Avoid a crash if the device tree is not assigning a codec to these links. [ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but active_mm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: events_unbound deferred_probe_work_func [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : __pi_strcmp+0x24/0x140 [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8 [ 1.203644] platform_probe+0x70/0xe8 [ 1.204106] really_probe+0xc8/0x3a0 [ 1.204556] __driver_probe_device+0x84/0x160 [ 1.205104] driver_probe_device+0x44/0x130 [ 1.205630] __device_attach_driver+0xc4/0x170 [ 1.206189] bus_for_each_drv+0x8c/0xf8 [ 1.206672] __device_attach+0xa8/0x1c8 [ 1.207155] device_initial_probe+0x1c/0x30 [ 1.207681] bus_probe_device+0xb0/0xc0 [ 1.208165] deferred_probe_work_func+0xa4/0x100 [ 1.208747] process_one_work+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38100", "url": "https://ubuntu.com/security/CVE-2025-38100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38102", "url": "https://ubuntu.com/security/CVE-2025-38102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify During our test, it is found that a warning can be trigger in try_grab_folio as follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]--- Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow: cpu0\t\t\tcpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page \t\t\tvmci_host_do_set_notify \t\t\tvmci_ctx_unset_notify \t\t\tnotify_page = context->notify_page; \t\t\tif (notify_page) \t\t\tput_page(notify_page);\t// page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38103", "url": "https://ubuntu.com/security/CVE-2025-38103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38107", "url": "https://ubuntu.com/security/CVE-2025-38107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: fix a race in ets_qdisc_change() Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38108", "url": "https://ubuntu.com/security/CVE-2025-38108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: red: fix a race in __red_change() Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38109", "url": "https://ubuntu.com/security/CVE-2025-38109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix ECVF vports unload on shutdown flow Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed. ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports. kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220 ---------------- [] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]---", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38304", "url": "https://ubuntu.com/security/CVE-2025-38304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38110", "url": "https://ubuntu.com/security/CVE-2025-38110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds clause 45 read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38111", "url": "https://ubuntu.com/security/CVE-2025-38111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38112", "url": "https://ubuntu.com/security/CVE-2025-38112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix TOCTOU issue in sk_is_readable() sk->sk_prot->sock_is_readable is a valid function pointer when sk resides in a sockmap. After the last sk_psock_put() (which usually happens when socket is removed from sockmap), sk->sk_prot gets restored and sk->sk_prot->sock_is_readable becomes NULL. This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded after the initial check. Which in turn may lead to a null pointer dereference. Ensure the function pointer does not turn NULL after the check.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38113", "url": "https://ubuntu.com/security/CVE-2025-38113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Fix NULL pointer dereference when nosmp is used With nosmp in cmdline, other CPUs are not brought up, leaving their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu() dereferences these NULL pointers, causing panic. Panic backtrace: [ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8 ... [ 0.403255] [] cppc_allow_fast_switch+0x6a/0xd4 ... Kernel panic - not syncing: Attempted to kill init! [ rjw: New subject ]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38088", "url": "https://ubuntu.com/security/CVE-2025-38088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size.", "cve_priority": "medium", "cve_public_date": "2025-06-30 08:15:00 UTC" }, { "cve": "CVE-2025-38115", "url": "https://ubuntu.com/security/CVE-2025-38115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: fix a potential crash on gso_skb handling SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 &", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38305", "url": "https://ubuntu.com/security/CVE-2025-38305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38117", "url": "https://ubuntu.com/security/CVE-2025-38117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Protect mgmt_pending list with its own lock This uses a mutex to protect from concurrent access of mgmt_pending list which can cause crashes like: ================================================================== BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318 CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38119", "url": "https://ubuntu.com/security/CVE-2025-38119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before. Backtrace: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 [ bvanassche: rewrote patch description ]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38307", "url": "https://ubuntu.com/security/CVE-2025-38307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Verify content returned by parse_int_array() The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38310", "url": "https://ubuntu.com/security/CVE-2025-38310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38120", "url": "https://ubuntu.com/security/CVE-2025-38120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo_avx2: fix initial map fill If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map. The early fix was incomplete and did only fix up the generic C implementation. A followup patch adds a test case to nft_concat_range.sh.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38122", "url": "https://ubuntu.com/security/CVE-2025-38122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo() did not check for this case before dereferencing the returned pointer. Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails. This improves robustness in low-memory scenarios.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38123", "url": "https://ubuntu.com/security/CVE-2025-38123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: Fix napi rx poll issue When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic. BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:dev_gro_receive+0x3a/0x620 [...] Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)] ? dev_gro_receive+0x3a/0x620 napi_gro_receive+0xad/0x170 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)] t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)] net_rx_action+0x103/0x470 irq_exit_rcu+0x13a/0x310 sysvec_apic_timer_interrupt+0x56/0x90 ", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38124", "url": "https://ubuntu.com/security/CVE-2025-38124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix udp gso skb_segment after pull from frag_list Commit a1e40ac5b5e9 (\"net: gso: fix udp gso fraglist segmentation after pull from frag_list\") detected invalid geometry in frag_list skbs and redirects them from skb_segment_list to more robust skb_segment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skb_segment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust. If only part of the fraglist payload is pulled into head_skb, it will always cause exception when splitting skbs by skb_segment. For detailed call stack information, see below. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify fraglist skbs, breaking these invariants. In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes. The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because payload was pulled into head_skb, it needs to be linearized before pass to regular skb_segment. skb_segment+0xcd0/0xd14 __udp_gso_segment+0x334/0x5f4 udp4_ufo_fragment+0x118/0x15c inet_gso_segment+0x164/0x338 skb_mac_gso_segment+0xc4/0x13c __skb_gso_segment+0xc4/0x124 validate_xmit_skb+0x9c/0x2c0 validate_xmit_skb_list+0x4c/0x80 sch_direct_xmit+0x70/0x404 __dev_queue_xmit+0x64c/0xe5c neigh_resolve_output+0x178/0x1c4 ip_finish_output2+0x37c/0x47c __ip_finish_output+0x194/0x240 ip_finish_output+0x20/0xf4 ip_output+0x100/0x1a0 NF_HOOK+0xc4/0x16c ip_forward+0x314/0x32c ip_rcv+0x90/0x118 __netif_receive_skb+0x74/0x124 process_backlog+0xe8/0x1a4 __napi_poll+0x5c/0x1f8 net_rx_action+0x154/0x314 handle_softirqs+0x154/0x4b8 [118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000 [118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14 [118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14 [118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38126", "url": "https://ubuntu.com/security/CVE-2025-38126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping The stmmac platform drivers that do not open-code the clk_ptp_rate value after having retrieved the default one from the device-tree can end up with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8) Prevent this division by 0 by adding an explicit check and error log about the actual issue. While at it, remove the same check from stmmac_ptp_register, which then becomes duplicate", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38127", "url": "https://ubuntu.com/security/CVE-2025-38127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix Tx scheduler error handling in XDP callback When the XDP program is loaded, the XDP callback adds new Tx queues. This means that the callback must update the Tx scheduler with the new queue number. In the event of a Tx scheduler failure, the XDP callback should also fail and roll back any changes previously made for XDP preparation. The previous implementation had a bug that not all changes made by the XDP callback were rolled back. This caused the crash with the following call trace: [ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5 [ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI [ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary) [ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022 [ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice] [...] [ +0.002715] Call Trace: [ +0.002452] [ +0.002021] ? __die_body.cold+0x19/0x29 [ +0.003922] ? die_addr+0x3c/0x60 [ +0.003319] ? exc_general_protection+0x17c/0x400 [ +0.004707] ? asm_exc_general_protection+0x26/0x30 [ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice] [ +0.004835] ice_napi_poll+0x665/0x680 [ice] [ +0.004320] __napi_poll+0x28/0x190 [ +0.003500] net_rx_action+0x198/0x360 [ +0.003752] ? update_rq_clock+0x39/0x220 [ +0.004013] handle_softirqs+0xf1/0x340 [ +0.003840] ? sched_clock_cpu+0xf/0x1f0 [ +0.003925] __irq_exit_rcu+0xc2/0xe0 [ +0.003665] common_interrupt+0x85/0xa0 [ +0.003839] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40 [ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690 Fix this by performing the missing unmapping of XDP queues from q_vectors and setting the XDP rings pointer back to NULL after all those queues are released. Also, add an immediate exit from the XDP callback in case of ring preparation failure.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38131", "url": "https://ubuntu.com/security/CVE-2025-38131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: prevent deactivate active config while enabling the config While enable active config via cscfg_csdev_enable_active_config(), active config could be deactivated via configfs' sysfs interface. This could make UAF issue in below scenario: CPU0 CPU1 (sysfs enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() unload module // access to config_desc which freed // while unloading module. cscfg_csdev_enable_config To address this, use cscfg_config_desc's active_cnt as a reference count which will be holded when - activate the config. - enable the activated config. and put the module reference when config_active_cnt == 0.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38274", "url": "https://ubuntu.com/security/CVE-2025-38274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: fix potential null pointer deref in fpga_mgr_test_img_load_sgt() fpga_mgr_test_img_load_sgt() allocates memory for sgt using kunit_kzalloc() however it does not check if the allocation failed. It then passes sgt to sg_alloc_table(), which passes it to __sg_alloc_table(). This function calls memset() on sgt in an attempt to zero it out. If the allocation fails then sgt will be NULL and the memset will trigger a NULL pointer dereference. Fix this by checking the allocation with KUNIT_ASSERT_NOT_ERR_OR_NULL().", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38135", "url": "https://ubuntu.com/security/CVE-2025-38135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: Fix potential null-ptr-deref in mlb_usio_probe() devm_ioremap() can return NULL on error. Currently, mlb_usio_probe() does not check for this case, which could result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38136", "url": "https://ubuntu.com/security/CVE-2025-38136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Reorder clock handling and power management in probe Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access before enabling clocks Since `iowrite16()` is performed without ensuring the required clocks are enabled, this can lead to access errors. To fix this, enable PM runtime early in the probe function and ensure clocks are acquired before register access, preventing crashes like the following on RZ/V2H: [13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP [13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750 [13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Call trace: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38138", "url": "https://ubuntu.com/security/CVE-2025-38138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Add NULL check in udma_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, udma_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38275", "url": "https://ubuntu.com/security/CVE-2025-38275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38142", "url": "https://ubuntu.com/security/CVE-2025-38142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (asus-ec-sensors) check sensor index in read_string() Prevent a potential invalid memory access when the requested sensor is not found. find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info(). Add a proper check to return -EINVAL if sensor_index is negative. Found by Linux Verification Center (linuxtesting.org) with SVACE. [groeck: Return error code returned from find_ec_sensor_index]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38277", "url": "https://ubuntu.com/security/CVE-2025-38277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: nand: ecc-mxic: Fix use of uninitialized variable ret If ctx->steps is zero, the loop processing ECC steps is skipped, and the variable ret remains uninitialized. It is later checked and returned, which leads to undefined behavior and may cause unpredictable results in user space or kernel crashes. This scenario can be triggered in edge cases such as misconfigured geometry, ECC engine misuse, or if ctx->steps is not validated after initialization. Initialize ret to zero before the loop to ensure correct and safe behavior regardless of the ctx->steps value. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38143", "url": "https://ubuntu.com/security/CVE-2025-38143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: pm8941: Add NULL check in wled_configure() devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38312", "url": "https://ubuntu.com/security/CVE-2025-38312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38145", "url": "https://ubuntu.com/security/CVE-2025-38145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop() devm_kasprintf() returns NULL when memory allocation fails. Currently, aspeed_lpc_enable_snoop() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. [arj: Fix Fixes: tag to use subject from 3772e5da4454]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38313", "url": "https://ubuntu.com/security/CVE-2025-38313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix double-free on mc_dev The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is a false-positive. WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38415", "url": "https://ubuntu.com/security/CVE-2025-38415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check return result of sb_min_blocksize Syzkaller reports an \"UBSAN: shift-out-of-bounds in squashfs_bio_read\" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl(\"/dev/loop0\", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize().", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38146", "url": "https://ubuntu.com/security/CVE-2025-38146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix the dead loop of MPLS parse The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally. stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type '__be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0 ", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38147", "url": "https://ubuntu.com/security/CVE-2025-38147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: calipso: Don't call calipso functions for AF_INET sk. syzkaller reported a null-ptr-deref in txopt_get(). [0] The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo, so struct ipv6_pinfo was NULL there. However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6 is always set in inet6_create(), meaning the socket was not IPv6 one. The root cause is missing validation in netlbl_conn_setattr(). netlbl_conn_setattr() switches branches based on struct sockaddr.sa_family, which is passed from userspace. However, netlbl_conn_setattr() does not check if the address family matches the socket. The syzkaller must have called connect() for an IPv6 address on an IPv4 socket. We have a proper validation in tcp_v[46]_connect(), but security_socket_connect() is called in the earlier stage. Let's copy the validation to netlbl_conn_setattr(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:txopt_get include/net/ipv6.h:390 [inline] RIP: 0010: Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00 RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070 RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00 R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80 FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f901b61a12d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003 RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in:", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38278", "url": "https://ubuntu.com/security/CVE-2025-38278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: QOS: Refactor TC_HTB_LEAF_DEL_LAST callback This patch addresses below issues, 1. Active traffic on the leaf node must be stopped before its send queue is reassigned to the parent. This patch resolves the issue by marking the node as 'Inner'. 2. During a system reboot, the interface receives TC_HTB_LEAF_DEL and TC_HTB_LEAF_DEL_LAST callbacks to delete its HTB queues. In the case of TC_HTB_LEAF_DEL_LAST, although the same send queue is reassigned to the parent, the current logic still attempts to update the real number of queues, leadning to below warnings New queues can't be registered after device unregistration. WARNING: CPU: 0 PID: 6475 at net/core/net-sysfs.c:1714 netdev_queue_update_kobjects+0x1e4/0x200", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38148", "url": "https://ubuntu.com/security/CVE-2025-38148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: mscc: Fix memory leak when using one step timestamping Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38149", "url": "https://ubuntu.com/security/CVE-2025-38149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clear phydev->devlink when the link is deleted There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the \"error\" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows. [ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is deleted.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38280", "url": "https://ubuntu.com/security/CVE-2025-38280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid __bpf_prog_ret0_warn when jit fails syzkaller reported an issue: WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Modules linked in: CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ... When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable. This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog, but jit failed due to FAULT_INJECTION. As a result, incorrectly treats the program as valid, when the program runs it calls `__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38153", "url": "https://ubuntu.com/security/CVE-2025-38153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: fix error handling of usbnet read calls Syzkaller, courtesy of syzbot, identified an error (see report [1]) in aqc111 driver, caused by incomplete sanitation of usb read calls' results. This problem is quite similar to the one fixed in commit 920a9fa27e78 (\"net: asix: add proper error handling of usb read errors\"). For instance, usbnet_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will not check its result properly. As [1] shows, this may lead to MAC address in aqc111_bind() being only partly initialized, triggering KMSAN warnings. Fix the issue by verifying that the number of bytes read is as expected and not less. [1] Partial syzbot report: BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38154", "url": "https://ubuntu.com/security/CVE-2025-38154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Avoid using sk_socket after free when sending The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected. Race conditions: ''' CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here ''' The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } ''' Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions. With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work. If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync(). In summary, we require synchronization to coordinate the backlog thread and close() thread. The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38155", "url": "https://ubuntu.com/security/CVE-2025-38155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init().", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38282", "url": "https://ubuntu.com/security/CVE-2025-38282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernfs: Relax constraint in draining guard The active reference lifecycle provides the break/unbreak mechanism but the active reference is not truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of kn->active counting. Assuming this mechanism is in place, the WARN check in kernfs_should_drain_open_files() is too sensitive -- it may transiently catch those (rightful) callers between kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen Ridong: \tkernfs_remove_by_name_ns\tkernfs_get_active // active=1 \t__kernfs_remove\t\t\t\t\t // active=0x80000002 \tkernfs_drain\t\t\t... \twait_event \t//waiting (active == 0x80000001) \t\t\t\t\tkernfs_break_active_protection \t\t\t\t\t// active = 0x80000001 \t// continue \t\t\t\t\tkernfs_unbreak_active_protection \t\t\t\t\t// active = 0x80000002 \t... \tkernfs_should_drain_open_files \t// warning occurs \t\t\t\t\tkernfs_put_active To avoid the false positives (mind panic_on_warn) remove the check altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with larger rework.)", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38157", "url": "https://ubuntu.com/security/CVE-2025-38157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Abort software beacon handling if disabled A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38283", "url": "https://ubuntu.com/security/CVE-2025-38283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: bugfix live migration function without VF device driver If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors. Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38158", "url": "https://ubuntu.com/security/CVE-2025-38158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: fix XQE dma address error The dma addresses of EQE and AEQE are wrong after migration and results in guest kernel-mode encryption services failure. Comparing the definition of hardware registers, we found that there was an error when the data read from the register was combined into an address. Therefore, the address combination sequence needs to be corrected. Even after fixing the above problem, we still have an issue where the Guest from an old kernel can get migrated to new kernel and may result in wrong data. In order to ensure that the address is correct after migration, if an old magic number is detected, the dma address needs to be updated.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-39890", "url": "https://ubuntu.com/security/CVE-2025-39890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event Currently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_caps is not freed in the failure case, causing a memory leak. The following trace is observed in kmemleak: unreferenced object 0xffff8b3eb5789c00 (size 1024): comm \"softirq\", pid 0, jiffies 4294942577 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{... 01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8.. backtrace (crc 44e1c357): __kmalloc_noprof+0x30b/0x410 ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k] ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k] ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k] ath12k_ce_recv_process_cb+0x218/0x300 [ath12k] ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k] process_one_work+0x219/0x680 bh_worker+0x198/0x1f0 tasklet_action+0x13/0x30 handle_softirqs+0xca/0x460 __irq_exit_rcu+0xbe/0x110 irq_exit_rcu+0x9/0x30 Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-09-24 11:15:00 UTC" }, { "cve": "CVE-2025-38159", "url": "https://ubuntu.com/security/CVE-2025-38159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38285", "url": "https://ubuntu.com/security/CVE-2025-38285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix WARN() in get_bpf_raw_tp_regs syzkaller reported an issue: WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38286", "url": "https://ubuntu.com/security/CVE-2025-38286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91: Fix possible out-of-boundary access at91_gpio_probe() doesn't check that given OF alias is not available or something went wrong when trying to get it. This might have consequences when accessing gpio_chips array with that value as an index. Note, that BUG() can be compiled out and hence won't actually perform the required checks.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38160", "url": "https://ubuntu.com/security/CVE-2025-38160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Add NULL check in raspberrypi_clk_register() devm_kasprintf() returns NULL when memory allocation fails. Currently, raspberrypi_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38161", "url": "https://ubuntu.com/security/CVE-2025-38161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure. Now properly rollback the object to its original state upon such failure. In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38290", "url": "https://ubuntu.com/security/CVE-2025-38290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath12k_core_halt() only reinitializes the \"arvifs\" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head \"arvifs\", but the next of the list head \"arvifs\" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head \"arvifs\" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute normally. Call trace: __list_del_entry_valid_or_report+0xd4/0x100 (P) ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k] ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k] cfg80211_wiphy_work+0xfc/0x100 process_one_work+0x164/0x2d0 worker_thread+0x254/0x380 kthread+0xfc/0x100 ret_from_fork+0x10/0x20 The change is mostly copied from the ath11k patch: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38163", "url": "https://ubuntu.com/security/CVE-2025-38163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sbi->total_valid_block_count syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94 The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38165", "url": "https://ubuntu.com/security/CVE-2025-38165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix panic when calling skb_linearize The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000 Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events sk_psock_backlog ... [ 657.469610] [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? do_trap+0x1d0/0x270 [ 657.470118] ? pskb_expand_head+0x612/0xf40 [ 657.470376] ? pskb_expand_head+0x612/0xf40 [ 657.470620] ? do_error_trap+0xa3/0x170 [ 657.470846] ? pskb_expand_head+0x612/0xf40 [ 657.471092] ? handle_invalid_op+0x2c/0x40 [ 657.471335] ? pskb_expand_head+0x612/0xf40 [ 657.471579] ? exc_invalid_op+0x2d/0x40 [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20 [ 657.472052] ? pskb_expand_head+0xd1/0xf40 [ 657.472292] ? pskb_expand_head+0x612/0xf40 [ 657.472540] ? lock_acquire+0x18f/0x4e0 [ 657.472766] ? find_held_lock+0x2d/0x110 [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10 [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470 [ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10 [ 657.473826] __pskb_pull_tail+0xfd/0x1d20 [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90 [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510 [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0 [ 657.476010] sk_psock_backlog+0x5cf/0xd70 [ 657.476637] process_one_work+0x858/0x1a20 ''' The panic originates from the assertion BUG_ON(skb_shared(skb)) in skb_linearize(). A previous commit(see Fixes tag) introduced skb_get() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed. The \"--rx-strp 100000\" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize. To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue. ''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress____________ ↓ | | → sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply_________________↑ skb_linearize ''' Note that for verdict_apply path, the skb_get operation is unnecessary so we add 'take_ref' param to control it's behavior.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38166", "url": "https://ubuntu.com/security/CVE-2025-38166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix ktls panic with sockmap [ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ...... After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data(). If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); ''' The changes in this commit are based on the following considerations: 1. When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic. 2. We can not calculate the correct number of bytes to revert msg_iter. Assume the original data is \"abcdefgh\" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: \"abc?de?fgh?\". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes \"?fgh?\" will be cached until the length meets the cork_bytes requirement. However, some data in \"?fgh?\" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data \"?\" we pushed. So it doesn't seem as simple as just reverting through an offset of msg_iter. 3. For non-TLS sockets in tcp_bpf_sendmsg, when a \"cork\" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached. Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { \tif (ret == -ENOSPC) \t\tret = 0; \tgoto send_end; ''' So it's ok to just return 'copied' without error when a \"cork\" situation occurs.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38293", "url": "https://ubuntu.com/security/CVE-2025-38293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the \"arvifs\" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head \"arvifs\", but the next of the list head \"arvifs\" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head \"arvifs\" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally. Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38295", "url": "https://ubuntu.com/security/CVE-2025-38295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create() The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses smp_processor_id(), which assumes disabled preemption. This leads to kernel warnings during module loading because meson_ddr_pmu_create() can be called in a preemptible context. Following kernel warning and stack trace: [ 31.745138] [ T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289 [ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38 [ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0 [ 31.745181] [ T2289] Tainted: [W]=WARN [ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT) [ 31.745188] [ T2289] Call trace: [ 31.745191] [ T2289] show_stack+0x28/0x40 (C) [ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198 [ 31.745205] [ T2289] dump_stack+0x20/0x50 [ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0 [ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38 [ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745246] [ T2289] platform_probe+0x98/0xe0 [ 31.745254] [ T2289] really_probe+0x144/0x3f8 [ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180 [ 31.745261] [ T2289] driver_probe_device+0x54/0x268 [ 31.745264] [ T2289] __driver_attach+0x11c/0x288 [ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160 [ 31.745274] [ T2289] driver_attach+0x34/0x50 [ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0 [ 31.745281] [ T2289] driver_register+0x78/0x120 [ 31.745285] [ T2289] __platform_driver_register+0x30/0x48 [ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745298] [ T2289] do_one_initcall+0x11c/0x438 [ 31.745303] [ T2289] do_init_module+0x68/0x228 [ 31.745311] [ T2289] load_module+0x118c/0x13a8 [ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390 [ 31.745320] [ T2289] invoke_syscall+0x74/0x108 [ 31.745326] [ T2289] el0_svc_common+0x90/0xf8 [ 31.745330] [ T2289] do_el0_svc+0x2c/0x48 [ 31.745333] [ T2289] el0_svc+0x60/0x150 [ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118 [ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0 Changes replaces smp_processor_id() with raw_smp_processor_id() to ensure safe CPU ID retrieval in preemptible contexts.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38167", "url": "https://ubuntu.com/security/CVE-2025-38167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: handle hdr_first_de() return value The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently. Additionally, error handling for the return value already exists at other points where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38170", "url": "https://ubuntu.com/security/CVE-2025-38170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Discard stale CPU state when handling SME traps The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad (\"arm64/sve: Discard stale CPU state when handling SVE traps\") The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g. | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Note: this was originallly posted as [1]. [ Rutland: rewrite commit message ]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38319", "url": "https://ubuntu.com/security/CVE-2025-38319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38298", "url": "https://ubuntu.com/security/CVE-2025-38298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/skx_common: Fix general protection fault After loading i10nm_edac (which automatically loads skx_edac_common), if unload only i10nm_edac, then reload it and perform error injection testing, a general protection fault may occur: mce: [Hardware Error]: Machine check events logged Oops: general protection fault ... ... Workqueue: events mce_gen_pool_process RIP: 0010:string+0x53/0xe0 ... Call Trace: ? die_addr+0x37/0x90 ? exc_general_protection+0x1e7/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? string+0x53/0xe0 vsnprintf+0x23e/0x4c0 snprintf+0x4d/0x70 skx_adxl_decode+0x16a/0x330 [skx_edac_common] skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common] skx_mce_check_error+0x17/0x20 [skx_edac_common] ... The issue arose was because the variable 'adxl_component_count' (inside skx_edac_common), which counts the ADXL components, was not reset. During the reloading of i10nm_edac, the count was incremented by the actual number of ADXL components again, resulting in a count that was double the real number of ADXL components. This led to an out-of-bounds reference to the ADXL component array, causing the general protection fault above. Fix this issue by resetting the 'adxl_component_count' in adxl_put(), which is called during the unloading of {skx,i10nm}_edac.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38173", "url": "https://ubuntu.com/security/CVE-2025-38173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/cesa - Handle zero-length skcipher requests Do not access random memory for zero-length skcipher requests. Just return 0.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38300", "url": "https://ubuntu.com/security/CVE-2025-38300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare() Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare(): 1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the \"theend_sgs\" error path, call dma unmap only if the corresponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the \"theend_iv\" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- To fix this, check for !dma_mapping_error() before calling dma_unmap_single() on the \"theend_iv\" path.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38174", "url": "https://ubuntu.com/security/CVE-2025-38174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Do not double dequeue a configuration request Some of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30 The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be scheduled twice for a request: first time via frame.callback from ring_work() and second time from tb_cfg_request(). Both times kworkers will execute tb_cfg_request_dequeue(), which results in double list_del() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122). Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE bit set.", "cve_priority": "medium", "cve_public_date": "2025-07-04 11:15:00 UTC" }, { "cve": "CVE-2025-38265", "url": "https://ubuntu.com/security/CVE-2025-38265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: jsm: fix NPE during jsm_uart_port_init No device was set which caused serial_base_ctrl_add to crash. BUG: kernel NULL pointer dereference, address: 0000000000000050 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1 Debian 6.12.25-1 RIP: 0010:serial_base_ctrl_add+0x96/0x120 Call Trace: serial_core_register_port+0x1a0/0x580 ? __setup_irq+0x39c/0x660 ? __kmalloc_cache_noprof+0x111/0x310 jsm_uart_port_init+0xe8/0x180 [jsm] jsm_probe_one+0x1f4/0x410 [jsm] local_pci_probe+0x42/0x90 pci_device_probe+0x22f/0x270 really_probe+0xdb/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8c/0xe0 bus_add_driver+0x112/0x1f0 driver_register+0x72/0xd0 jsm_init_module+0x36/0xff0 [jsm] ? __pfx_jsm_init_module+0x10/0x10 [jsm] do_one_initcall+0x58/0x310 do_init_module+0x60/0x230 Tested with Digi Neo PCIe 8 port card.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38053", "url": "https://ubuntu.com/security/CVE-2025-38053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix null-ptr-deref in idpf_features_check idpf_features_check is used to validate the TX packet. skb header length is compared with the hardware supported value received from the device control plane. The value is stored in the adapter structure and to access it, vport pointer is used. During reset all the vports are released and the vport pointer that the netdev private structure points to is NULL. To avoid null-ptr-deref, store the max header length value in netdev private structure. This also helps to cache the value and avoid accessing adapter pointer in hot path. BUG: kernel NULL pointer dereference, address: 0000000000000068 ... RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf] Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38055", "url": "https://ubuntu.com/security/CVE-2025-38055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq Currently, using PEBS-via-PT with a sample frequency instead of a sample period, causes a segfault. For example: BUG: kernel NULL pointer dereference, address: 0000000000000195 ? __die_body.cold+0x19/0x27 ? page_fault_oops+0xca/0x290 ? exc_page_fault+0x7e/0x1b0 ? asm_exc_page_fault+0x26/0x30 ? intel_pmu_pebs_event_update_no_drain+0x40/0x60 ? intel_pmu_pebs_event_update_no_drain+0x32/0x60 intel_pmu_drain_pebs_icl+0x333/0x350 handle_pmi_common+0x272/0x3c0 intel_pmu_handle_irq+0x10a/0x2e0 perf_event_nmi_handler+0x2a/0x50 That happens because intel_pmu_pebs_event_update_no_drain() assumes all the pebs_enabled bits represent counter indexes, which is not always the case. In this particular case, bits 60 and 61 are set for PEBS-via-PT purposes. The behaviour of PEBS-via-PT with sample frequency is questionable because although a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is not adjusted anyway. Putting that aside, fix intel_pmu_pebs_event_update_no_drain() by passing the mask of counter bits instead of 'size'. Note, prior to the Fixes commit, 'size' would be limited to the maximum counter index, so the issue was not hit.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38057", "url": "https://ubuntu.com/security/CVE-2025-38057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38060", "url": "https://ubuntu.com/security/CVE-2025-38060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: copy_verifier_state() should copy 'loop_entry' field The bpf_verifier_state.loop_entry state should be copied by copy_verifier_state(). Otherwise, .loop_entry values from unrelated states would poison env->cur_state. Additionally, env->stack should not contain any states with .loop_entry != NULL. The states in env->stack are yet to be verified, while .loop_entry is set for states that reached an equivalent state. This means that env->cur_state->loop_entry should always be NULL after pop_stack(). See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix. This change has some verification performance impact for selftests: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- ------------- arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%) And significant negative impact for sched_ext: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------ bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scx_qmap.bpf.o qmap_dispatch ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38098", "url": "https://ubuntu.com/security/CVE-2025-38098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Don't treat wb connector as physical in create_validate_stream_for_sink Don't try to operate on a drm_wb_connector as an amdgpu_dm_connector. While dereferencing aconnector->base will \"work\" it's wrong and might lead to unknown bad things. Just... don't.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38099", "url": "https://ubuntu.com/security/CVE-2025-38099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken A SCO connection without the proper voice_setting can cause the controller to lock up.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38073", "url": "https://ubuntu.com/security/CVE-2025-38073", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38051", "url": "https://ubuntu.com/security/CVE-2025-38051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_fill_dirent There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 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 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== POC is available in the link [1]. The problem triggering process is as follows: Process 1 Process 2 ----------------------------------- ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38077", "url": "https://ubuntu.com/security/CVE-2025-38077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store() If the 'buf' array received from the user contains an empty string, the 'length' variable will be zero. Accessing the 'buf' array element with index 'length - 1' will result in a buffer overflow. Add a check for an empty string. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38078", "url": "https://ubuntu.com/security/CVE-2025-38078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race of buffer access at PCM OSS layer The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38003", "url": "https://ubuntu.com/security/CVE-2025-38003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu read protection for procfs content When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF). As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.", "cve_priority": "medium", "cve_public_date": "2025-06-08 11:15:00 UTC" }, { "cve": "CVE-2025-38004", "url": "https://ubuntu.com/security/CVE-2025-38004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.", "cve_priority": "medium", "cve_public_date": "2025-06-08 11:15:00 UTC" }, { "cve": "CVE-2025-38031", "url": "https://ubuntu.com/security/CVE-2025-38031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: do not leak refcount in reorder_work A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented. Fix this by checking the return value of queue_work() and decrementing the refcount when necessary. Resolves: Unreferenced object 0xffff9d9f421e3d80 (size 192): comm \"cryptomgr_probe\", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38079", "url": "https://ubuntu.com/security/CVE-2025-38079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_hash - fix double free in hash_accept If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38052", "url": "https://ubuntu.com/security/CVE-2025-38052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38097", "url": "https://ubuntu.com/security/CVE-2025-38097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used \"recently\", but it's a lot more complex than just not caching the socket.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38058", "url": "https://ubuntu.com/security/CVE-2025-38058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38059", "url": "https://ubuntu.com/security/CVE-2025-38059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid NULL pointer dereference if no valid csum tree [BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace: BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Call Trace: scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE] Mount option \"rescue=idatacsums\" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification. Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all. This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash. [FIX] Check both extent and csum tree root before doing any tree search.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38034", "url": "https://ubuntu.com/security/CVE-2025-38034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref btrfs_prelim_ref() calls the old and new reference variables in the incorrect order. This causes a NULL pointer dereference because oldref is passed as NULL to trace_btrfs_prelim_ref_insert(). Note, trace_btrfs_prelim_ref_insert() is being called with newref as oldref (and oldref as NULL) on purpose in order to print out the values of newref. To reproduce: echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable Perform some writeback operations. Backtrace: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38035", "url": "https://ubuntu.com/security/CVE-2025-38035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: don't restore null sk_state_change queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if the TCP connection isn't established when nvmet_tcp_set_queue_sock() is called then queue->state_change isn't set and sock->sk->sk_state_change isn't replaced. As such we don't need to restore sock->sk->sk_state_change if queue->state_change is NULL. This avoids NULL pointer dereferences such as this: [ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode [ 286.463796][ C0] #PF: error_code(0x0010) - not-present page [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0 [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary) [ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 286.467147][ C0] RIP: 0010:0x0 [ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246 [ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43 [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100 [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3 [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268 [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000 [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0 [ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 286.475453][ C0] Call Trace: [ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440 [ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60 [ 286.478174][ C0] ? __build_skb_around+0x234/0x330 [ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10 [ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0 [ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30 [ 286.482769][ C0] ? ktime_get+0x66/0x150 [ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050 [ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0 [ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10 [ 286.486917][ C0] ? lock_release+0x217/0x2c0 [ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0 [ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30 [ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0 [ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10 [ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10 [ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack] [ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370 [ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420 [ 286.494268][ C0] ip_local_deliver+0x168/0x430 [ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10 [ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20 [ 286.496806][ C0] ? lock_release+0x217/0x2c0 [ 286.497414][ C0] ip_rcv+0x455/0x6e0 [ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10 [ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38037", "url": "https://ubuntu.com/security/CVE-2025-38037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Annotate FDB data races The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2]. Suppress these reports by annotating these accesses using READ_ONCE() / WRITE_ONCE(). [1] BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f Reported by Kernel Concurrency Sanitizer on: CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38039", "url": "https://ubuntu.com/security/CVE-2025-38039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled When attempting to enable MQPRIO while HTB offload is already configured, the driver currently returns `-EINVAL` and triggers a `WARN_ON`, leading to an unnecessary call trace. Update the code to handle this case more gracefully by returning `-EOPNOTSUPP` instead, while also providing a helpful user message.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38080", "url": "https://ubuntu.com/security/CVE-2025-38080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase block_sequence array size [Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash. [How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38040", "url": "https://ubuntu.com/security/CVE-2025-38040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: mctrl_gpio: split disable_ms into sync and no_sync APIs The following splat has been observed on a SAMA5D27 platform using atmel_serial: BUG: sleeping function called from invalid context at kernel/irq/manage.c:738 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0 preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<00000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7bec softirqs last enabled at (0): [] copy_process+0x1ca0/0x7bec softirqs last disabled at (0): [<00000000>] 0x0 CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74 Hardware name: Atmel SAMA5 Workqueue: hci0 hci_power_on [bluetooth] Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28 This warning is emitted when trying to toggle, at the highest level, some flow control (with serdev_device_set_flow_control) in a device driver. At the lowest level, the atmel_serial driver is using serial_mctrl_gpio lib to enable/disable the corresponding IRQs accordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to disable_irq (called in mctrl_gpio_disable_ms) being possibly called in some atomic context (some tty drivers perform modem lines configuration in regions protected by port lock). Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one and a blocking one. Replace mctrl_gpio_disable_ms calls with the relevant version depending on whether the call is protected by some port lock.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38061", "url": "https://ubuntu.com/security/CVE-2025-38061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix access outside of user given buffer in pktgen_thread_write() Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer).", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38062", "url": "https://ubuntu.com/security/CVE-2025-38062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie The IOMMU translation for MSI message addresses has been a 2-step process, separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address. This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached. Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the \"container\" after starting up. However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()). This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs. Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor. The other UAF related to iommu_get_domain_for_dev() will be addressed in patch \"iommu: Make iommu_dma_prepare_msi() into a generic operation\" by using the IOMMU group mutex.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38063", "url": "https://ubuntu.com/security/CVE-2025-38063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix unconditional IO throttle caused by REQ_PREFLUSH When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush() generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, which causes the flush_bio to be throttled by wbt_wait(). An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: \"kworker/u260:0\" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4 After commit 2def2845cc33 (\"xfs: don't allow log IO to be throttled\"), the metadata submitted by xlog_write_iclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled. Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes wbt_should_throttle() return false to avoid wbt_wait().", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38043", "url": "https://ubuntu.com/security/CVE-2025-38043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Set dma_mask for ffa devices Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning: WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38044", "url": "https://ubuntu.com/security/CVE-2025-38044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: set device_caps for 417 The video_device for the MPEG encoder did not set device_caps. Add this, otherwise the video device can't be registered (you get a WARN_ON instead). Not seen before since currently 417 support is disabled, but I found this while experimenting with it.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38065", "url": "https://ubuntu.com/security/CVE-2025-38065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: Do not truncate file size 'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38066", "url": "https://ubuntu.com/security/CVE-2025-38066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: prevent BUG_ON by blocking retries on failed device resumes A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object. Reproduce steps: 1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata. cat <> cmeta.xml EOF dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta 2. wipe the second array block of the mapping array to simulate data degradations. mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\ 2>/dev/null | hexdump -e '1/8 \"%u\\n\"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\ 2>/dev/null | hexdump -e '1/8 \"%u\\n\"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try bringing up the cache device. The resume is expected to fail due to the broken array block. dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dmsetup create cache --notable dmsetup load cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup resume cache 4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings. dmsetup resume cache Kernel logs: (snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570 Fix by disallowing resume operations for devices that failed the initial attempt.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38068", "url": "https://ubuntu.com/security/CVE-2025-38068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: lzo - Fix compression buffer overrun Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller. Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38045", "url": "https://ubuntu.com/security/CVE-2025-38045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix debug actions order The order of actions taken for debug was implemented incorrectly. Now we implemented the dump split and do the FW reset only in the middle of the dump (rather than the FW killing itself on error.) As a result, some of the actions taken when applying the config will now crash the device, so we need to fix the order.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38071", "url": "https://ubuntu.com/security/CVE-2025-38071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Check return value from memblock_phys_alloc_range() At least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of contiguous free memory available at this point, the kernel will crash and burn because memblock_phys_alloc_range() returns 0 on failure, which leads memblock_phys_free() to throw the first 4 MiB of physical memory to the wolves. At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine without the weird reserve allocation.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38072", "url": "https://ubuntu.com/security/CVE-2025-38072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Fix divide error in nd_label_data_init() If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Code and flow: 1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer is set to zero (nvdimm driver): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) A subsequent DIV_ROUND_UP() causes a division by zero: drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Fix this by checking the config size parameter by extending an existing check.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38081", "url": "https://ubuntu.com/security/CVE-2025-38081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi-rockchip: Fix register out of bounds access Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38074", "url": "https://ubuntu.com/security/CVE-2025-38074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: protect vq->log_used with vq->mutex The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); \t\t\t\t QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38048", "url": "https://ubuntu.com/security/CVE-2025-38048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_ring: Fix data race by tagging event_triggered as racy for KCSAN syzbot reports a data-race when accessing the event_triggered, here is the simplified stack when the issue occurred: ================================================================== BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayed write to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3800 [inline] read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline] value changed: 0x01 -> 0x00 ================================================================== When the data race occurs, the function virtqueue_enable_cb_delayed() sets event_triggered to false, and virtqueue_disable_cb_split/packed() reads it as false due to the race condition. Since event_triggered is an unreliable hint used for optimization, this should only cause the driver temporarily suggest that the device not send an interrupt notification when the event index is used. Fix this KCSAN reported data-race issue by explicitly tagging the access as data_racy.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38075", "url": "https://ubuntu.com/security/CVE-2025-38075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix timeout on deleted connection NOPIN response timer may expire on a deleted connection and crash with such logs: Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 That is because nopin response timer may be re-started on nopin timer expiration. Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-37968", "url": "https://ubuntu.com/security/CVE-2025-37968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: opt3001: fix deadlock due to concurrent flag access The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-38011", "url": "https://ubuntu.com/security/CVE-2025-38011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: csa unmap use uninterruptible lock After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace. Change to use uninterruptible wait lock fix the issue. WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu] Call Trace: drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.isra.0+0x65/0x70 [drm] drm_release+0x6a/0x120 [drm] amdgpu_drm_release+0x51/0x60 [amdgpu] __fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0 (cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-21931", "url": "https://ubuntu.com/security/CVE-2025-21931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio Commit b15c87263a69 (\"hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page. However folio lock must be held before calling try_to_unmap. Add it to fix this problem. Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2025-37960", "url": "https://ubuntu.com/security/CVE-2025-37960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memblock: Accept allocated memory before use in memblock_double_array() When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest: RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b Mitigate this by calling accept_memory() on the memory range returned before the slab is available. Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37967", "url": "https://ubuntu.com/security/CVE-2025-37967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix deadlock This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-22102", "url": "https://ubuntu.com/security/CVE-2025-22102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix kernel panic during FW release This fixes a kernel panic seen during release FW in a stress test scenario where WLAN and BT FW download occurs simultaneously, and due to a HW bug, chip sends out only 1 bootloader signatures. When driver receives the bootloader signature, it enters FW download mode, but since no consequtive bootloader signatures seen, FW file is not requested. After 60 seconds, when FW download times out, release_firmware causes a kernel panic. [ 2601.949184] Unable to handle kernel paging request at virtual address 0000312e6f006573 [ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000 [ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000 [ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP [ 2601.992091] Modules linked in: algif_hash algif_skcipher af_alg btnxpuart(O) pciexxx(O) mlan(O) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce snd_soc_fsl_easrc snd_soc_fsl_asoc_card imx8_media_dev(C) snd_soc_fsl_micfil polyval_generic snd_soc_fsl_xcvr snd_soc_fsl_sai snd_soc_imx_audmux snd_soc_fsl_asrc snd_soc_imx_card snd_soc_imx_hdmi snd_soc_fsl_aud2htx snd_soc_fsl_utils imx_pcm_dma dw_hdmi_cec flexcan can_dev [ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G C O 6.6.23-lts-next-06236-gb586a521770e #1 [ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2602.010191] pc : _raw_spin_lock+0x34/0x68 [ 2602.010201] lr : free_fw_priv+0x20/0xfc [ 2602.020561] sp : ffff800089363b30 [ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000 [ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000 [ 2602.020577] x23: ffff0000dc856f38 [ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000 [ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000 [ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480 [ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002 [ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30 [ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000 [ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001 [ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573 [ 2602.083354] Call trace: [ 2602.083356] _raw_spin_lock+0x34/0x68 [ 2602.083364] release_firmware+0x48/0x6c [ 2602.083370] nxp_setup+0x3c4/0x540 [btnxpuart] [ 2602.083383] hci_dev_open_sync+0xf0/0xa34 [ 2602.083391] hci_dev_open+0xd8/0x178 [ 2602.083399] hci_sock_ioctl+0x3b0/0x590 [ 2602.083405] sock_do_ioctl+0x60/0x118 [ 2602.083413] sock_ioctl+0x2f4/0x374 [ 2602.091430] __arm64_sys_ioctl+0xac/0xf0 [ 2602.091437] invoke_syscall+0x48/0x110 [ 2602.091445] el0_svc_common.constprop.0+0xc0/0xe0 [ 2602.091452] do_el0_svc+0x1c/0x28 [ 2602.091457] el0_svc+0x40/0xe4 [ 2602.091465] el0t_64_sync_handler+0x120/0x12c [ 2602.091470] el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38008", "url": "https://ubuntu.com/security/CVE-2025-38008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix race condition in unaccepted memory handling The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machinery detects it: WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 The comment around the WARN() explains the problem: \t/* \t * Warn about the '-1' case though; since that means a \t * decrement is concurrent with a first (0->1) increment. IOW \t * people are trying to disable something that wasn't yet fully \t * enabled. This suggests an ordering problem on the user side. \t */ The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38014", "url": "https://ubuntu.com/security/CVE-2025-38014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Refactor remove call with idxd_cleanup() helper The idxd_cleanup() helper cleans up perfmon, interrupts, internals and so on. Refactor remove call with the idxd_cleanup() helper to avoid code duplication. Note, this also fixes the missing put_device() for idxd groups, enginces and wqs.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38015", "url": "https://ubuntu.com/security/CVE-2025-38015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix memory leak in error handling path of idxd_alloc Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38005", "url": "https://ubuntu.com/security/CVE-2025-38005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma: Add missing locking Recent kernels complain about a missing lock in k3-udma.c when the lock validator is enabled: [ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28 [ 4.144867] Hardware name: pp-v12 (DT) [ 4.148648] Workqueue: events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udma_start.isra.0+0x34/0x238 [ 4.165227] lr : udma_start.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udma_start.isra.0+0x34/0x238 [ 4.251509] udma_check_tx_completion+0xd0/0xdc [ 4.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] ret_from_fork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28 [ 4.311559] ---[ end trace 0000000000000000 ]--- This commit adds the missing locking.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38009", "url": "https://ubuntu.com/security/CVE-2025-38009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: disable napi on driver removal A warning on driver removal started occurring after commit 9dd05df8403b (\"net: warn if NAPI instance wasn't shut down\"). Disable tx napi before deleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Tested with mt7921e but the same pattern can be actually applied to other mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled in their *_dma_init() functions and only toggled off and on again inside their suspend/resume/reset paths. So it should be okay to disable tx napi in such a generic way. Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38010", "url": "https://ubuntu.com/security/CVE-2025-38010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as: [ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270 The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 (\"xhci: tegra: USB2 pad power controls\"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count. To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually. With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles. The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38095", "url": "https://ubuntu.com/security/CVE-2025-38095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-buf: insert memory barrier before updating num_fences smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered.", "cve_priority": "medium", "cve_public_date": "2025-07-03 08:15:00 UTC" }, { "cve": "CVE-2025-38018", "url": "https://ubuntu.com/security/CVE-2025-38018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix kernel panic when alloc_page failed We cannot set frag_list to NULL pointer when alloc_page failed. It will be used in tls_strp_check_queue_ok when the next time tls_strp_read_sock is called. This is because we don't reset full_len in tls_strp_flush_anchor_copy() so the recv path will try to continue handling the partial record on the next call but we dettached the rcvq from the frag list. Alternative fix would be to reset full_len. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Call trace: tls_strp_check_rcv+0x128/0x27c tls_strp_data_ready+0x34/0x44 tls_data_ready+0x3c/0x1f0 tcp_data_ready+0x9c/0xe4 tcp_data_queue+0xf6c/0x12d0 tcp_rcv_established+0x52c/0x798", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38019", "url": "https://ubuntu.com/security/CVE-2025-38019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices: # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP (Note that the neighbor is not marked with 'offload') When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one: # devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted: # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1 Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38013", "url": "https://ubuntu.com/security/CVE-2025-38013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request Make sure that n_channels is set after allocating the struct cfg80211_registered_device::int_scan_req member. Seen with syzkaller: UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]') This was missed in the initial conversions because I failed to locate the allocation likely due to the \"sizeof(void *)\" not matching the \"channels\" array type.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38027", "url": "https://ubuntu.com/security/CVE-2025-38027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: max20086: fix invalid memory access max20086_parse_regulators_dt() calls of_regulator_match() using an array of struct of_regulator_match allocated on the stack for the matches argument. of_regulator_match() calls devm_of_regulator_put_matches(), which calls devres_alloc() to allocate a struct devm_of_regulator_matches which will be de-allocated using devm_of_regulator_put_matches(). struct devm_of_regulator_matches is populated with the stack allocated matches array. If the device fails to probe, devm_of_regulator_put_matches() will be called and will try to call of_node_put() on that stack pointer, generating the following dmesg entries: max20086 6-0028: Failed to read DEVICE_ID reg: -121 kobject: '\\xc0$\\xa5\\x03' (000000002cebcb7a): is not initialized, yet kobject_put() is being called. Followed by a stack trace matching the call flow described above. Switch to allocating the matches array using devm_kcalloc() to avoid accessing the stack pointer long after it's out of scope. This also has the advantage of allowing multiple max20086 to probe without overriding the data stored inside the global of_regulator_match.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38020", "url": "https://ubuntu.com/security/CVE-2025-38020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Disable MACsec offload for uplink representor profile MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features. If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set. Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features(). Kernel log: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sen ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38094", "url": "https://ubuntu.com/security/CVE-2025-38094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cadence: macb: Fix a possible deadlock in macb_halt_tx. There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.", "cve_priority": "medium", "cve_public_date": "2025-07-03 08:15:00 UTC" }, { "cve": "CVE-2025-38006", "url": "https://ubuntu.com/security/CVE-2025-38006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox \"ip addr show\". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-37992", "url": "https://ubuntu.com/security/CVE-2025-37992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: Flush gso_skb list too during ->change() Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.", "cve_priority": "medium", "cve_public_date": "2025-05-26 15:15:00 UTC" }, { "cve": "CVE-2025-38023", "url": "https://ubuntu.com/security/CVE-2025-38023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: handle failure of nfs_get_lock_context in unlock path When memory is insufficient, the allocation of nfs_lock_context in nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM) as valid and proceed to execute rpc_run_task(), this will trigger a NULL pointer dereference in nfs4_locku_prepare. For example: BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]--- Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and return NULL to terminate subsequent rpc_run_task, preventing NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38007", "url": "https://ubuntu.com/security/CVE-2025-38007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Add NULL check in uclogic_input_configured() devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38024", "url": "https://ubuntu.com/security/CVE-2025-38024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur. The solution is to let rxe_cleanup do all the work.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-37957", "url": "https://ubuntu.com/security/CVE-2025-37957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception Previously, commit ed129ec9057f (\"KVM: x86: forcibly leave nested mode on vCPU reset\") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM). This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault The issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do _something_ sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI. So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [sean: massage changelog, make it clear this isn't architectural behavior]", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37963", "url": "https://ubuntu.com/security/CVE-2025-37963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37948", "url": "https://ubuntu.com/security/CVE-2025-37948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37994", "url": "https://ubuntu.com/security/CVE-2025-37994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix NULL pointer access This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.", "cve_priority": "medium", "cve_public_date": "2025-05-29 14:15:00 UTC" }, { "cve": "CVE-2025-37995", "url": "https://ubuntu.com/security/CVE-2025-37995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.", "cve_priority": "medium", "cve_public_date": "2025-05-29 14:15:00 UTC" }, { "cve": "CVE-2025-37949", "url": "https://ubuntu.com/security/CVE-2025-37949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xenbus: Use kref to track req lifetime Marek reported seeing a NULL pointer fault in the xenbus_thread callstack: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: e030:__wake_up_common+0x4c/0x180 Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0 process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems like it was xs_wake_up() in this case. It seems like req may have woken up the xs_wait_for_reply(), which kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed data. Linux Device Drivers 2nd edition states: \"Normally, a wake_up call can cause an immediate reschedule to happen, meaning that other processes might run before wake_up returns.\" ... which would match the behaviour observed. Change to keeping two krefs on each request. One for the caller, and one for xenbus_thread. Each will kref_put() when finished, and the last will free it. This use of kref matches the description in Documentation/core-api/kref.rst", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37954", "url": "https://ubuntu.com/security/CVE-2025-37954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Avoid race in open_cached_dir with lease breaks A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs. Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37951", "url": "https://ubuntu.com/security/CVE-2025-37951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Add job to pending list if the reset was skipped When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1] and [2]. Similarly to commit 704d3d60fec4 (\"drm/etnaviv: don't block scheduler when GPU is still active\"), this patch ensures the job is put back on the pending list when extending the timeout.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37969", "url": "https://ubuntu.com/security/CVE-2025-37969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37970", "url": "https://ubuntu.com/security/CVE-2025-37970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37972", "url": "https://ubuntu.com/security/CVE-2025-37972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: mtk-pmic-keys - fix possible null pointer dereference In mtk_pmic_keys_probe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer. Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37959", "url": "https://ubuntu.com/security/CVE-2025-37959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Scrub packet on bpf_redirect_peer When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be \"misused\" in another namespace. As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2, In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption. This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37961", "url": "https://ubuntu.com/security/CVE-2025-37961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix uninit-value for saddr in do_output_route4 syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 (\"ipvs: do not use random local source address for tunnels\") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37998", "url": "https://ubuntu.com/security/CVE-2025-37998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.", "cve_priority": "medium", "cve_public_date": "2025-05-29 14:15:00 UTC" }, { "cve": "CVE-2025-37952", "url": "https://ubuntu.com/security/CVE-2025-37952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix UAF in __close_file_table_ids A use-after-free is possible if one thread destroys the file via __ksmbd_close_fd while another thread holds a reference to it. The existing checks on fp->refcount are not sufficient to prevent this. The fix takes ft->lock around the section which removes the file from the file table. This prevents two threads acquiring the same file pointer via __close_file_table_ids, as well as the other functions which retrieve a file from the IDR and which already use this same lock.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37947", "url": "https://ubuntu.com/security/CVE-2025-37947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds stream writes by validating *pos ksmbd_vfs_stream_write() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (v_len). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write. This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37956", "url": "https://ubuntu.com/security/CVE-2025-37956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent rename with empty string Client can send empty newname string to ksmbd server. It will cause a kernel oops from d_alloc. This patch return the error when attempting to rename a file or directory with an empty new name string.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37973", "url": "https://ubuntu.com/security/CVE-2025-37973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation Currently during the multi-link element defragmentation process, the multi-link element length added to the total IEs length when calculating the length of remaining IEs after the multi-link element in cfg80211_defrag_mle(). This could lead to out-of-bounds access if the multi-link element or its corresponding fragment elements are the last elements in the IEs buffer. To address this issue, correctly calculate the remaining IEs length by deducting the multi-link element end offset from total IEs end offset.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37920", "url": "https://ubuntu.com/security/CVE-2025-37920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37900", "url": "https://ubuntu.com/security/CVE-2025-37900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu: Fix two issues in iommu_copy_struct_from_user() In the review for iommu_copy_struct_to_user() helper, Matt pointed out that a NULL pointer should be rejected prior to dereferencing it: https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com And Alok pointed out a typo at the same time: https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com Since both issues were copied from iommu_copy_struct_from_user(), fix them first in the current header.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37931", "url": "https://ubuntu.com/security/CVE-2025-37931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: adjust subpage bit start based on sectorsize When running machines with 64k page size and a 16k nodesize we started seeing tree log corruption in production. This turned out to be because we were not writing out dirty blocks sometimes, so this in fact affects all metadata writes. When writing out a subpage EB we scan the subpage bitmap for a dirty range. If the range isn't dirty we do \tbit_start++; to move onto the next bit. The problem is the bitmap is based on the number of sectors that an EB has. So in this case, we have a 64k pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4 bits for every node. With a 64k page size we end up with 4 nodes per page. To make this easier this is how everything looks [0 16k 32k 48k ] logical address [0 4 8 12 ] radix tree offset [ 64k page ] folio [ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers [ | | | | | | | | | | | | | | | | ] bitmap Now we use all of our addressing based on fs_info->sectorsize_bits, so as you can see the above our 16k eb->start turns into radix entry 4. When we find a dirty range for our eb, we correctly do bit_start += sectors_per_node, because if we start at bit 0, the next bit for the next eb is 4, to correspond to eb->start 16k. However if our range is clean, we will do bit_start++, which will now put us offset from our radix tree entries. In our case, assume that the first time we check the bitmap the block is not dirty, we increment bit_start so now it == 1, and then we loop around and check again. This time it is dirty, and we go to find that start using the following equation \tstart = folio_start + bit_start * fs_info->sectorsize; so in the case above, eb->start 0 is now dirty, and we calculate start as \t0 + 1 * fs_info->sectorsize = 4096 \t4096 >> 12 = 1 Now we're looking up the radix tree for 1, and we won't find an eb. What's worse is now we're using bit_start == 1, so we do bit_start += sectors_per_node, which is now 5. If that eb is dirty we will run into the same thing, we will look at an offset that is not populated in the radix tree, and now we're skipping the writeout of dirty extent buffers. The best fix for this is to not use sectorsize_bits to address nodes, but that's a larger change. Since this is a fs corruption problem fix it simply by always using sectors_per_node to increment the start bit.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37903", "url": "https://ubuntu.com/security/CVE-2025-37903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix slab-use-after-free in hdcp The HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connector objects without incrementing the kref reference counts. When using a USB-C dock, and the dock is unplugged, the corresponding amdgpu_dm_connector objects are freed, creating dangling pointers in the HDCP code. When the dock is plugged back, the dangling pointers are dereferenced, resulting in a slab-use-after-free: [ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10 [ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233 [ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024 [ 66.776186] Workqueue: events event_property_validate [amdgpu] [ 66.776494] Call Trace: [ 66.776496] [ 66.776497] dump_stack_lvl+0x70/0xa0 [ 66.776504] print_report+0x175/0x555 [ 66.776507] ? __virt_addr_valid+0x243/0x450 [ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0 [ 66.776515] kasan_report+0xeb/0x1c0 [ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.777121] __asan_report_load4_noabort+0x14/0x20 [ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.777342] ? __lock_acquire+0x6b40/0x6b40 [ 66.777347] ? enable_assr+0x250/0x250 [amdgpu] [ 66.777571] process_one_work+0x86b/0x1510 [ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0 [ 66.777578] ? assign_work+0x16b/0x280 [ 66.777580] ? lock_is_held_type+0xa3/0x130 [ 66.777583] worker_thread+0x5c0/0xfa0 [ 66.777587] ? process_one_work+0x1510/0x1510 [ 66.777588] kthread+0x3a2/0x840 [ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777594] ? trace_hardirqs_on+0x4f/0x60 [ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60 [ 66.777599] ? calculate_sigpending+0x77/0xa0 [ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777605] ret_from_fork+0x40/0x90 [ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777609] ret_from_fork_asm+0x11/0x20 [ 66.777614] [ 66.777643] Allocated by task 10: [ 66.777646] kasan_save_stack+0x39/0x60 [ 66.777649] kasan_save_track+0x14/0x40 [ 66.777652] kasan_save_alloc_info+0x37/0x50 [ 66.777655] __kasan_kmalloc+0xbb/0xc0 [ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0 [ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu] [ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper] [ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper] [ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper] [ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper] [ 66.777917] process_one_work+0x86b/0x1510 [ 66.777919] worker_thread+0x5c0/0xfa0 [ 66.777922] kthread+0x3a2/0x840 [ 66.777925] ret_from_fork+0x40/0x90 [ 66.777927] ret_from_fork_asm+0x11/0x20 [ 66.777932] Freed by task 1713: [ 66.777935] kasan_save_stack+0x39/0x60 [ 66.777938] kasan_save_track+0x14/0x40 [ 66.777940] kasan_save_free_info+0x3b/0x60 [ 66.777944] __kasan_slab_free+0x52/0x70 [ 66.777946] kfree+0x13f/0x4b0 [ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu] [ 66.778179] drm_connector_free+0x7d/0xb0 [ 66.778184] drm_mode_object_put.part.0+0xee/0x160 [ 66.778188] drm_mode_object_put+0x37/0x50 [ 66.778191] drm_atomic_state_default_clear+0x220/0xd60 [ 66.778194] __drm_atomic_state_free+0x16e/0x2a0 [ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0 [ 66.778200] drm_ioctl_kernel+0x17a/0x310 [ 66.778203] drm_ioctl+0x584/0xd10 [ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu] [ 66.778375] __x64_sys_ioctl+0x139/0x1a0 [ 66.778378] x64_sys_call+0xee7/0xfb0 [ 66.778381] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37905", "url": "https://ubuntu.com/security/CVE-2025-37905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Balance device refcount when destroying devices Using device_find_child() to lookup the proper SCMI device to destroy causes an unbalance in device refcount, since device_find_child() calls an implicit get_device(): this, in turns, inhibits the call of the provided release methods upon devices destruction. As a consequence, one of the structures that is not freed properly upon destruction is the internal struct device_private dev->p populated by the drivers subsystem core. KMemleak detects this situation since loading/unloding some SCMI driver causes related devices to be created/destroyed without calling any device_release method. unreferenced object 0xffff00000f583800 (size 512): comm \"insmod\", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158 $ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0 device_add+0x954/0x12d0: kmalloc_noprof at include/linux/slab.h:901 (inlined by) kzalloc_noprof at include/linux/slab.h:1037 (inlined by) device_private_init at drivers/base/core.c:3510 (inlined by) device_add at drivers/base/core.c:3561 Balance device refcount by issuing a put_device() on devices found via device_find_child().", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37933", "url": "https://ubuntu.com/security/CVE-2025-37933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeon_ep: Fix host hang issue during device reboot When the host loses heartbeat messages from the device, the driver calls the device-specific ndo_stop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndo_stop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndo_stop is not called.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37909", "url": "https://ubuntu.com/security/CVE-2025-37909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Fix memleak issue when GSO enabled Always map the `skb` to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37911", "url": "https://ubuntu.com/security/CVE-2025-37911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix out-of-bound memcpy() during ethtool -w When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption: BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80 ... This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf. In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information. This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37935", "url": "https://ubuntu.com/security/CVE-2025-37935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix SER panic with 4GB+ RAM If the mtk_poll_rx() function detects the MTK_RESETTING flag, it will jump to release_desc and refill the high word of the SDP on the 4GB RFB. Subsequently, mtk_rx_clean will process an incorrect SDP, leading to a panic. Add patch from MediaTek's SDK to resolve this.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37891", "url": "https://ubuntu.com/security/CVE-2025-37891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: Fix buffer overflow at UMP SysEx message conversion The conversion function from MIDI 1.0 to UMP packet contains an internal buffer to keep the incoming MIDI bytes, and its size is 4, as it was supposed to be the max size for a MIDI1 UMP packet data. However, the implementation overlooked that SysEx is handled in a different format, and it can be up to 6 bytes, as found in do_convert_to_ump(). It leads eventually to a buffer overflow, and may corrupt the memory when a longer SysEx message is received. The fix is simply to extend the buffer size to 6 to fit with the SysEx UMP message.", "cve_priority": "medium", "cve_public_date": "2025-05-19 08:15:00 UTC" }, { "cve": "CVE-2025-37912", "url": "https://ubuntu.com/security/CVE-2025-37912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr() As mentioned in the commit baeb705fd6a7 (\"ice: always check VF VSI pointer values\"), we need to perform a null pointer check on the return value of ice_get_vf_vsi() before using it.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37913", "url": "https://ubuntu.com/security/CVE-2025-37913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: qfq: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of qfq, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. This patch checks whether the class was already added to the agg->active list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37914", "url": "https://ubuntu.com/security/CVE-2025-37914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37915", "url": "https://ubuntu.com/security/CVE-2025-37915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: drr: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37916", "url": "https://ubuntu.com/security/CVE-2025-37916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: remove write-after-free of client_id A use-after-free error popped up in stress testing: [Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47): [Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core] [Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70 [Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180 [Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80 [Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0 [Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80 The actual device uninit usually happens on a separate thread scheduled after this code runs, but there is no guarantee of order of thread execution, so this could be a problem. There's no actual need to clear the client_id at this point, so simply remove the offending code.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37917", "url": "https://ubuntu.com/security/CVE-2025-37917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll Use spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock and spin_unlock in mtk_star_emac driver to avoid spinlock recursion occurrence that can happen when enabling the DMA interrupts again in rx/tx poll. ``` BUG: spinlock recursion on CPU#0, swapper/0/0 lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT Hardware name: MediaTek MT8365 Open Platform EVK (DT) Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x60/0x80 dump_stack+0x18/0x24 spin_dump+0x78/0x88 do_raw_spin_lock+0x11c/0x120 _raw_spin_lock+0x20/0x2c mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac] __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x4c/0xb0 handle_fasteoi_irq+0xa0/0x1bc handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x120 do_interrupt_handler+0x50/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 regmap_mmio_read32le+0xc/0x20 (P) _regmap_bus_reg_read+0x6c/0xac _regmap_read+0x60/0xdc regmap_read+0x4c/0x80 mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac] __napi_poll+0x38/0x188 net_rx_action+0x164/0x2c0 handle_softirqs+0x100/0x244 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x20 call_on_irq_stack+0x24/0x64 do_softirq_own_stack+0x1c/0x40 __irq_exit_rcu+0xd4/0x10c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 cpuidle_enter_state+0xac/0x320 (P) cpuidle_enter+0x38/0x50 do_idle+0x1e4/0x260 cpu_startup_entry+0x34/0x3c rest_init+0xdc/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ```", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37918", "url": "https://ubuntu.com/security/CVE-2025-37918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue() A NULL pointer dereference can occur in skb_dequeue() when processing a QCA firmware crash dump on WCN7851 (0489:e0f3). [ 93.672166] Bluetooth: hci0: ACL memdump size(589824) [ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth] [ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80 The issue stems from handle_dump_pkt_qca() returning 0 even when a dump packet is successfully processed. This is because it incorrectly forwards the return value of hci_devcd_init() (which returns 0 on success). As a result, the caller (btusb_recv_acl_qca() or btusb_recv_evt_qca()) assumes the packet was not handled and passes it to hci_recv_frame(), leading to premature kfree() of the skb. Later, hci_devcd_rx() attempts to dequeue the same skb from the dump queue, resulting in a NULL pointer dereference. Fix this by: 1. Making handle_dump_pkt_qca() return 0 on success and negative errno on failure, consistent with kernel conventions. 2. Splitting dump packet detection into separate functions for ACL and event packets for better structure and readability. This ensures dump packets are properly identified and consumed, avoiding double handling and preventing NULL pointer access.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37921", "url": "https://ubuntu.com/security/CVE-2025-37921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: Fix unlocked deletion of default FDB entry When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 (\"vxlan: Create wrappers for FDB lookup\"). Reproducer: # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0 Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it. [1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Call Trace: __vxlan_fdb_delete+0xbe/0x560 vxlan_vni_delete_group+0x2ba/0x940 vxlan_vni_del.isra.0+0x15f/0x580 vxlan_process_vni_filter+0x38b/0x7b0 vxlan_vnifilter_process+0x3bb/0x510 rtnetlink_rcv_msg+0x2f7/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37897", "url": "https://ubuntu.com/security/CVE-2025-37897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release plfxlc_mac_release() asserts that mac->lock is held. This assertion is incorrect, because even if it was possible, it would not be the valid behaviour. The function is used when probe fails or after the device is disconnected. In both cases mac->lock can not be held as the driver is not working with the device at the moment. All functions that use mac->lock unlock it just after it was held. There is also no need to hold mac->lock for plfxlc_mac_release() itself, as mac data is not affected, except for mac->flags, which is modified atomically. This bug leads to the following warning: ================================================================ WARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0 Modules linked in: CPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: usb_hub_wq hub_event RIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106 Call Trace: probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694 usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165 usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238 usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620 hub_port_connect drivers/usb/core/hub.c:5477 [inline] hub_port_connect_change drivers/usb/core/hub.c:5617 [inline] port_event drivers/usb/core/hub.c:5773 [inline] hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855 process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292 worker_thread+0xa47/0x1200 kernel/workqueue.c:2439 kthread+0x28d/0x320 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ================================================================ Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37922", "url": "https://ubuntu.com/security/CVE-2025-37922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: book3s64/radix : Align section vmemmap start address to PAGE_SIZE A vmemmap altmap is a device-provided region used to provide backing storage for struct pages. For each namespace, the altmap should belong to that same namespace. If the namespaces are created unaligned, there is a chance that the section vmemmap start address could also be unaligned. If the section vmemmap start address is unaligned, the altmap page allocated from the current namespace might be used by the previous namespace also. During the free operation, since the altmap is shared between two namespaces, the previous namespace may detect that the page does not belong to its altmap and incorrectly assume that the page is a normal page. It then attempts to free the normal page, which leads to a kernel crash. Kernel attempted to read user page (18) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000018 Faulting instruction address: 0xc000000000530c7c Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries CPU: 32 PID: 2104 Comm: ndctl Kdump: loaded Tainted: G W NIP: c000000000530c7c LR: c000000000530e00 CTR: 0000000000007ffe REGS: c000000015e57040 TRAP: 0300 Tainted: G W MSR: 800000000280b033 CR: 84482404 CFAR: c000000000530dfc DAR: 0000000000000018 DSISR: 40000000 IRQMASK: 0 GPR00: c000000000530e00 c000000015e572e0 c000000002c5cb00 c00c000101008040 GPR04: 0000000000000000 0000000000000007 0000000000000001 000000000000001f GPR08: 0000000000000005 0000000000000000 0000000000000018 0000000000002000 GPR12: c0000000001d2fb0 c0000060de6b0080 0000000000000000 c0000060dbf90020 GPR16: c00c000101008000 0000000000000001 0000000000000000 c000000125b20f00 GPR20: 0000000000000001 0000000000000000 ffffffffffffffff c00c000101007fff GPR24: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000004040201 0000000000000001 0000000000000000 c00c000101008040 NIP [c000000000530c7c] get_pfnblock_flags_mask+0x7c/0xd0 LR [c000000000530e00] free_unref_page_prepare+0x130/0x4f0 Call Trace: free_unref_page+0x50/0x1e0 free_reserved_page+0x40/0x68 free_vmemmap_pages+0x98/0xe0 remove_pte_table+0x164/0x1e8 remove_pmd_table+0x204/0x2c8 remove_pud_table+0x1c4/0x288 remove_pagetable+0x1c8/0x310 vmemmap_free+0x24/0x50 section_deactivate+0x28c/0x2a0 __remove_pages+0x84/0x110 arch_remove_memory+0x38/0x60 memunmap_pages+0x18c/0x3d0 devm_action_release+0x30/0x50 release_nodes+0x68/0x140 devres_release_group+0x100/0x190 dax_pmem_compat_release+0x44/0x80 [dax_pmem_compat] device_for_each_child+0x8c/0x100 [dax_pmem_compat_remove+0x2c/0x50 [dax_pmem_compat] nvdimm_bus_remove+0x78/0x140 [libnvdimm] device_remove+0x70/0xd0 Another issue is that if there is no altmap, a PMD-sized vmemmap page will be allocated from RAM, regardless of the alignment of the section start address. If the section start address is not aligned to the PMD size, a VM_BUG_ON will be triggered when setting the PMD-sized page to page table. In this patch, we are aligning the section vmemmap start address to PAGE_SIZE. After alignment, the start address will not be part of the current namespace, and a normal page will be allocated for the vmemmap mapping of the current section. For the remaining sections, altmaps will be allocated. During the free operation, the normal page will be correctly freed. In the same way, a PMD_SIZE vmemmap page will be allocated only if the section start address is PMD_SIZE-aligned; otherwise, it will fall back to a PAGE-sized vmemmap allocation. Without this patch ================== NS1 start NS2 start _________________________________________________________ | NS1 | NS2 | --------------------------------------------------------- | Altmap| Altmap | .....|Altmap| Altmap | ........... | NS1 | NS1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37923", "url": "https://ubuntu.com/security/CVE-2025-37923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix oob write in trace_seq_to_buffer() syzbot reported this bug: ================================================================== BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260 CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 .... ================================================================== It has been reported that trace_seq_to_buffer() tries to copy more data than PAGE_SIZE to buf. Therefore, to prevent this, we should use the smaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37924", "url": "https://ubuntu.com/security/CVE-2025-37924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37927", "url": "https://ubuntu.com/security/CVE-2025-37927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256. The same applies to the hid string with length 13 and uid string with length 250. Check the length of hid and uid strings separately to prevent buffer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37928", "url": "https://ubuntu.com/security/CVE-2025-37928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-bufio: don't schedule in atomic context A BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and try_verify_in_tasklet are enabled. [ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421 [ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4 [ 129.444740][ T934] preempt_count: 201, expected: 0 [ 129.444756][ T934] RCU nest depth: 0, expected: 0 [ 129.444781][ T934] Preemption disabled at: [ 129.444789][ T934] [] shrink_work+0x21c/0x248 [ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16! [ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0 [ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8 [ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT) [ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work [ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug] [ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c [ 129.447451][ T934] sp : ffffffc0843dbc90 [ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b [ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68 [ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900 [ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030 [ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358 [ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003 [ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400 [ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8 [ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0 [ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000 [ 129.447647][ T934] Call trace: [ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6] [ 129.447681][ T934] __might_resched+0x190/0x1a8 [ 129.447694][ T934] shrink_work+0x180/0x248 [ 129.447706][ T934] process_one_work+0x260/0x624 [ 129.447718][ T934] worker_thread+0x28c/0x454 [ 129.447729][ T934] kthread+0x118/0x158 [ 129.447742][ T934] ret_from_fork+0x10/0x20 [ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000) [ 129.447772][ T934] ---[ end trace 0000000000000000 ]--- dm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet is enabled, and __scan will be called in atomic context.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37990", "url": "https://ubuntu.com/security/CVE-2025-37990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage() The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions. Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized. Improve the error message to report more detailed error information.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37901", "url": "https://ubuntu.com/security/CVE-2025-37901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not have a corresponding MPM pin and should not be handled inside the MPM driver. The IRQ domain hierarchy is always applied, so it's required to explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but irq-qcom-mpm is currently missing the check. This is causing crashes when setting up interrupts for non-wake GPIOs: root@rb1:~# gpiomon -c gpiochip1 10 irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1 Unable to handle kernel paging request at virtual address ffff8000a1dc3820 Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT) pc : mpm_set_type+0x80/0xcc lr : mpm_set_type+0x5c/0xcc Call trace: mpm_set_type+0x80/0xcc (P) qcom_mpm_set_type+0x64/0x158 irq_chip_set_type_parent+0x20/0x38 msm_gpio_irq_set_type+0x50/0x530 __irq_set_trigger+0x60/0x184 __setup_irq+0x304/0x6bc request_threaded_irq+0xc8/0x19c edge_detector_setup+0x260/0x364 linereq_create+0x420/0x5a8 gpio_ioctl+0x2d4/0x6c0 Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that MPM is removed entirely from the hierarchy for non-wake GPIOs.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37936", "url": "https://ubuntu.com/security/CVE-2025-37936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value. When generating the MSR_IA32_PEBS_ENABLE value that will be loaded on VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE value. Consulting only the host kernel's host vs. guest masks results in running the guest with PEBS enabled even when the guest doesn't want to use PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply looking at exclude_host can't differentiate between events created by host userspace, and events created by KVM on behalf of the guest. Running the guest with PEBS unexpectedly enabled typically manifests as crashes due to a near-infinite stream of #PFs. E.g. if the guest hasn't written MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' when trying to record PEBS events. The issue is most easily reproduced by running `perf kvm top` from before commit 7b100989b4f6 (\"perf evlist: Remove __evlist__add_default\") (after which, `perf kvm top` effectively stopped using PEBS).\tThe userspace side of perf creates a guest-only PEBS event, which intel_guest_get_msrs() misconstrues a guest-*owned* PEBS event. Arguably, this is a userspace bug, as enabling PEBS on guest-only events simply cannot work, and userspace can kill VMs in many other ways (there is no danger to the host). However, even if this is considered to be bad userspace behavior, there's zero downside to perf/KVM restricting PEBS to guest-owned events. Note, commit 854250329c02 (\"KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations\") fixed the case where host userspace is profiling KVM *and* userspace, but missed the case where userspace is profiling only KVM.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37991", "url": "https://ubuntu.com/security/CVE-2025-37991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Fix double SIGFPE crash Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf(\"GOT signal %d with si_code %ld\\n\", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf(\"%lf\\n\",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@parisc:~# strace -f ./a.out execve(\"./a.out\", [\"./a.out\"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37930", "url": "https://ubuntu.com/security/CVE-2025-37930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill() Nouveau is mostly designed in a way that it's expected that fences only ever get signaled through nouveau_fence_signal(). However, in at least one other place, nouveau_fence_done(), can signal fences, too. If that happens (race) a signaled fence remains in the pending list for a while, until it gets removed by nouveau_fence_update(). Should nouveau_fence_context_kill() run in the meantime, this would be a bug because the function would attempt to set an error code on an already signaled fence. Have nouveau_fence_context_kill() check for a fence being signaled.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37986", "url": "https://ubuntu.com/security/CVE-2025-37986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: class: Invalidate USB device pointers on partner unregistration To avoid using invalid USB device pointers after a Type-C partner disconnects, this patch clears the pointers upon partner unregistration. This ensures a clean state for future connections.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37809", "url": "https://ubuntu.com/security/CVE-2025-37809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: class: Fix NULL pointer access Concurrent calls to typec_partner_unlink_device can lead to a NULL pointer dereference. This patch adds a mutex to protect USB device pointers and prevent this issue. The same mutex protects both the device pointers and the partner device registration.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37816", "url": "https://ubuntu.com/security/CVE-2025-37816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: vsc: Fix fortify-panic caused by invalid counted_by() use gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[] and the vsc-tp.c code is using this in a wrong way. len does not contain the available size in the buffer, it contains the actual packet length *without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to buf[] the fortify-panic handler gets triggered: [ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0 [ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50 ... [ 80.843175] __fortify_panic+0x9/0xb [ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw] [ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110 [ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc] [ 80.843270] mei_reset+0x11d/0x420 [mei] The easiest fix would be to just drop the counted-by but with the exception of the ack buffer in vsc_tp_xfer_helper() which only contains enough room for the packet-header, all other uses of vsc_tp_packet always use a buffer of VSC_TP_MAX_XFER_SIZE bytes for the packet. Instead of just dropping the counted-by, split the vsc_tp_packet struct definition into a header and a full-packet definition and use a fixed size buf[] in the packet definition, this way fortify-source buffer overrun checking still works when enabled.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37822", "url": "https://ubuntu.com/security/CVE-2025-37822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: uprobes: Add missing fence.i after building the XOL buffer The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions. This was found running the BPF selftests \"test_progs: uprobe_autoattach, attach_probe\" on the Spacemit K1/X60, where the uprobes tests randomly blew up.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37987", "url": "https://ubuntu.com/security/CVE-2025-37987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: Prevent possible adminq overflow/stuck condition The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion. On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW. As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37826", "url": "https://ubuntu.com/security/CVE-2025-37826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer() Add a NULL check for the returned hwq pointer by ufshcd_mcq_req_to_hwq(). This is similar to the fix in commit 74736103fb41 (\"scsi: ufs: core: Fix ufshcd_abort_one racing issue\").", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37827", "url": "https://ubuntu.com/security/CVE-2025-37827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: return EIO on RAID1 block group write pointer mismatch There was a bug report about a NULL pointer dereference in __btrfs_add_free_space_zoned() that ultimately happens because a conversion from the default metadata profile DUP to a RAID1 profile on two disks. The stack trace has the following signature: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ end trace 0000000000000000 ]--- The 1st line is the most interesting here: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile When a RAID1 block-group is created and a write pointer mismatch between the disks in the RAID set is detected, btrfs sets the alloc_offset to the length of the block group marking it as full. Afterwards the code expects that a balance operation will evacuate the data in this block-group and repair the problems. But before this is possible, the new space of this block-group will be accounted in the free space cache. But in __btrfs_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37977", "url": "https://ubuntu.com/security/CVE-2025-37977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: exynos: Disable iocc if dma-coherent property isn't set If dma-coherent property isn't set then descriptors are non-cacheable and the iocc shareability bits should be disabled. Without this UFS can end up in an incompatible configuration and suffer from random cache related stability issues.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37944", "url": "https://ubuntu.com/security/CVE-2025-37944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry to fetch the next entry from the destination ring. This is incorrect because ath12k_hal_srng_src_get_next_entry is intended for source rings, not destination rings. This leads to invalid entry fetches, causing potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source ring and destination ring have different handling mechanisms and using the wrong function results in incorrect pointer arithmetic and ring management. To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry with ath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensures that the correct function is used for fetching entries from the destination ring, preventing invalid memory accesses. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37761", "url": "https://ubuntu.com/security/CVE-2025-37761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix an out-of-bounds shift when invalidating TLB When the size of the range invalidated is larger than rounddown_pow_of_two(ULONG_MAX), The function macro roundup_pow_of_two(length) will hit an out-of-bounds shift [1]. Use a full TLB invalidation for such cases. v2: - Use a define for the range size limit over which we use a full TLB invalidation. (Lucas) - Use a better calculation of the limit. [1]: [ 39.202421] ------------[ cut here ]------------ [ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10 [ 39.202690] Tainted: [U]=USER [ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 39.202691] Call Trace: [ 39.202692] [ 39.202695] dump_stack_lvl+0x6e/0xa0 [ 39.202699] ubsan_epilogue+0x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe] [ 39.202800] ? find_held_lock+0x2b/0x80 [ 39.202803] ? mark_held_locks+0x40/0x70 [ 39.202806] xe_svm_invalidate+0x459/0x700 [xe] [ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm] [ 39.202900] __mmu_notifier_release+0x1f5/0x270 [ 39.202905] exit_mmap+0x40e/0x450 [ 39.202912] __mmput+0x45/0x110 [ 39.202914] exit_mm+0xc5/0x130 [ 39.202916] do_exit+0x21c/0x500 [ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190 [ 39.202920] do_group_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290 [ 39.202932] do_syscall_64+0xa1/0x180 [ 39.202934] ? do_user_addr_fault+0x59f/0x8a0 [ 39.202937] ? lock_release+0xd2/0x2a0 [ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0 [ 39.202942] ? trace_hardirqs_off+0x4b/0xc0 [ 39.202944] ? clear_bhb_loop+0x25/0x80 [ 39.202946] ? clear_bhb_loop+0x25/0x80 [ 39.202947] ? clear_bhb_loop+0x25/0x80 [ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 39.202952] RIP: 0033:0x7fa945e543e1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293 [ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3 [ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff [ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0 [ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000 [ 39.202970] [ 39.202970] ---[ end trace ]--- (cherry picked from commit b88f48f86500bc0b44b4f73ac66d500a40d320ad)", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37763", "url": "https://ubuntu.com/security/CVE-2025-37763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: take paired job reference For paired jobs, have the fragment job take a reference on the geometry job, so that the geometry job cannot be freed until the fragment job has finished with it. The geometry job structure is accessed when the fragment job is being prepared by the GPU scheduler. Taking the reference prevents the geometry job being freed until the fragment job no longer requires it. Fixes a use after free bug detected by KASAN: [ 124.256386] BUG: KASAN: slab-use-after-free in pvr_queue_prepare_job+0x108/0x868 [powervr] [ 124.264893] Read of size 1 at addr ffff0000084cb960 by task kworker/u16:4/63", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37764", "url": "https://ubuntu.com/security/CVE-2025-37764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix firmware memory leaks Free the memory used to hold the results of firmware image processing when the module is unloaded. Fix the related issue of the same memory being leaked if processing of the firmware image fails during module load. Ensure all firmware GEM objects are destroyed if firmware image processing fails. Fixes memory leaks on powervr module unload detected by Kmemleak: unreferenced object 0xffff000042e20000 (size 94208): comm \"modprobe\", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE. d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H. backtrace (crc dd329dec): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xaa4/0x1f50 [powervr] unreferenced object 0xffff000042d20000 (size 20480): comm \"modprobe\", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................ 00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................ backtrace (crc 395b02e3): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xb0c/0x1f50 [powervr]", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37869", "url": "https://ubuntu.com/security/CVE-2025-37869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37978", "url": "https://ubuntu.com/security/CVE-2025-37978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: integrity: Do not call set_page_dirty_lock() Placing multiple protection information buffers inside the same page can lead to oopses because set_page_dirty_lock() can't be called from interrupt context. Since a protection information buffer is not backed by a file there is no point in setting its page dirty, there is nothing to synchronize. Drop the call to set_page_dirty_lock() and remove the last argument to bio_integrity_unpin_bvec().", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37975", "url": "https://ubuntu.com/security/CVE-2025-37975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: module: Fix out-of-bounds relocation access The current code allows rel[j] to access one element past the end of the relocation section. Simplify to num_relocations which is equivalent to the existing size expression.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37872", "url": "https://ubuntu.com/security/CVE-2025-37872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix memory leak in txgbe_probe() error path When txgbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in txgbe_probe() function, the subsequent error paths after txgbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when txgbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init().", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37873", "url": "https://ubuntu.com/security/CVE-2025-37873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: fix missing ring index trim on error path Commit under Fixes converted tx_prod to be free running but missed masking it on the Tx error path. This crashes on error conditions, for example when DMA mapping fails.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-22120", "url": "https://ubuntu.com/security/CVE-2025-22120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: goto right label 'out_mmap_sem' in ext4_setattr() Otherwise, if ext4_inode_attach_jinode() fails, a hung task will happen because filemap_invalidate_unlock() isn't called to unlock mapping->invalidate_lock. Like this: EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory INFO: task fsstress:374 blocked for more than 122 seconds. Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:fsstress state:D stack:0 pid:374 tgid:374 ppid:373 task_flags:0x440140 flags:0x00000000 Call Trace: __schedule+0x2c9/0x7f0 schedule+0x27/0xa0 schedule_preempt_disabled+0x15/0x30 rwsem_down_read_slowpath+0x278/0x4c0 down_read+0x59/0xb0 page_cache_ra_unbounded+0x65/0x1b0 filemap_get_pages+0x124/0x3e0 filemap_read+0x114/0x3d0 vfs_read+0x297/0x360 ksys_read+0x6c/0xe0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-37799", "url": "https://ubuntu.com/security/CVE-2025-37799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp vmxnet3 driver's XDP handling is buggy for packet sizes using ring0 (that is, packet sizes between 128 - 3k bytes). We noticed MTU-related connectivity issues with Cilium's service load- balancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP backend service where the XDP LB was doing IPIP encap led to overly large packet sizes but only for *some* of the packets (e.g. HTTP GET request) while others (e.g. the prior TCP 3WHS) looked completely fine on the wire. In fact, the pcap recording on the backend node actually revealed that the node with the XDP LB was leaking uninitialized kernel data onto the wire for the affected packets, for example, while the packets should have been 152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes was padded with whatever other data was in that page at the time (e.g. we saw user/payload data from prior processed packets). We only noticed this through an MTU issue, e.g. when the XDP LB node and the backend node both had the same MTU (e.g. 1500) then the curl request got dropped on the backend node's NIC given the packet was too large even though the IPIP-encapped packet normally would never even come close to the MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let the curl request succeed (which also indicates that the kernel ignored the padding, and thus the issue wasn't very user-visible). Commit e127ce7699c1 (\"vmxnet3: Fix missing reserved tailroom\") was too eager to also switch xdp_prepare_buff() from rcd->len to rbi->len. It really needs to stick to rcd->len which is the actual packet length from the descriptor. The latter we also feed into vmxnet3_process_xdp_small(), by the way, and it indicates the correct length needed to initialize the xdp->{data,data_end} parts. For e127ce7699c1 (\"vmxnet3: Fix missing reserved tailroom\") the relevant part was adapting xdp_init_buff() to address the warning given the xdp_data_hard_end() depends on xdp->frame_sz. With that fixed, traffic on the wire looks good again.", "cve_priority": "medium", "cve_public_date": "2025-05-03 12:15:00 UTC" }, { "cve": "CVE-2025-37800", "url": "https://ubuntu.com/security/CVE-2025-37800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential NULL pointer dereference in dev_uevent() If userspace reads \"uevent\" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it. Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing.", "cve_priority": "low", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37878", "url": "https://ubuntu.com/security/CVE-2025-37878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init Move the get_ctx(child_ctx) call and the child_event->ctx assignment to occur immediately after the child event is allocated. Ensure that child_event->ctx is non-NULL before any subsequent error path within inherit_event calls free_event(), satisfying the assumptions of the cleanup code. Details: There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression. The code initially incremented refcount then assigned context immediately after the child_event was created. Later, an early validity check for child_event was added before the refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was added, assuming event->ctx is valid if the pmu_ctx is valid. The problem is that the WARN_ON_ONCE() could trigger after the initial check passed but before child_event->ctx was assigned, violating its precondition. The solution is to assign child_event->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARN_ON_ONCE(). To resolve it, defer the refcount update and child_event->ctx assignment directly after child_event->pmu_ctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmu_ctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in child_ctx to find_get_pmu_context before its refcount/assignment. [ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37803", "url": "https://ubuntu.com/security/CVE-2025-37803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udmabuf: fix a buf size overflow issue during udmabuf creation by casting size_limit_mb to u64 when calculate pglimit.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37879", "url": "https://ubuntu.com/security/CVE-2025-37879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p/net: fix improper handling of bogus negative read/write replies In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37983", "url": "https://ubuntu.com/security/CVE-2025-37983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qibfs: fix _another_ leak failure to allocate inode => leaked dentry... this one had been there since the initial merge; to be fair, if we are that far OOM, the odds of failing at that particular allocation are low...", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37881", "url": "https://ubuntu.com/security/CVE-2025-37881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 (\"ice: Fix some null pointer dereference issues in ice_ptp.c\"). This issue is found by our static analysis tool", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37805", "url": "https://ubuntu.com/security/CVE-2025-37805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound/virtio: Fix cancel_sync warnings on uninitialized work_structs Betty reported hitting the following warning: [ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc [ 8.713570][ T221] cancel_work_sync+0x24/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390 [ 8.714139][ T221] really_probe+0x1bc/0x4c8 ... It seems we're hitting the error path in virtsnd_probe(), which triggers a virtsnd_remove() which iterates over the substreams calling cancel_work_sync() on the elapsed_period work_struct. Looking at the code, from earlier in: virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg() We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsnd_ctl_query_info() fails, we will exit without having initialized the elapsed_period work_struct. When that error path unwinds we then call virtsnd_remove() which as long as the substreams array is allocated, will iterate through calling cancel_work_sync() on the uninitialized work struct hitting this warning. Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data. Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing. Feedback or thoughts would be appreciated!", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37883", "url": "https://ubuntu.com/security/CVE-2025-37883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Add check for get_zeroed_page() Add check for the return value of get_zeroed_page() in sclp_console_init() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37884", "url": "https://ubuntu.com/security/CVE-2025-37884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix deadlock between rcu_tasks_trace and event_mutex. Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegate trace_set_clr_event() to workqueue to avoid such lock dependency.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37808", "url": "https://ubuntu.com/security/CVE-2025-37808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: null - Use spin lock instead of mutex As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37985", "url": "https://ubuntu.com/security/CVE-2025-37985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: wdm: close race between wdm_open and wdm_wwan_port_stop Clearing WDM_WWAN_IN_USE must be the last action or we can open a chardev whose URBs are still poisoned", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37810", "url": "https://ubuntu.com/security/CVE-2025-37810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: check that event count does not exceed event buffer length The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37811", "url": "https://ubuntu.com/security/CVE-2025-37811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: ci_hdrc_imx: fix usbmisc handling usbmisc is an optional device property so it is totally valid for the corresponding data->usbmisc_data to have a NULL value. Check that before dereferencing the pointer. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37812", "url": "https://ubuntu.com/security/CVE-2025-37812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: Fix deadlock when using NCM gadget The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 (\"usb: cdnsp: Fix deadlock issue during using NCM gadget\"). Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using \"iperf --bidir\" over NCM ethernet link. The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37813", "url": "https://ubuntu.com/security/CVE-2025-37813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix invalid pointer dereference in Etron workaround This check is performed before prepare_transfer() and prepare_ring(), so enqueue can already point at the final link TRB of a segment. And indeed it will, some 0.4% of times this code is called. Then enqueue + 1 is an invalid pointer. It will crash the kernel right away or load some junk which may look like a link TRB and cause the real link TRB to be replaced with a NOOP. This wouldn't end well. Use a functionally equivalent test which doesn't dereference the pointer and always gives correct result. Something has crashed my machine twice in recent days while playing with an Etron HC, and a control transfer stress test ran for confirmation has just crashed it again. The same test passes with this patch applied.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37815", "url": "https://ubuntu.com/security/CVE-2025-37815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration Resolve kernel panic while accessing IRQ handler associated with the generated IRQ. This is done by acquiring the spinlock and storing the current interrupt state before handling the interrupt request using generic_handle_irq. A previous fix patch was submitted where 'generic_handle_irq' was replaced with 'handle_nested_irq'. However, this change also causes the kernel panic where after determining which GPIO triggered the interrupt and attempting to call handle_nested_irq with the mapped IRQ number, leads to a failure in locating the registered handler.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37885", "url": "https://ubuntu.com/security/CVE-2025-37885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn't postable Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.", "cve_priority": "low", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37817", "url": "https://ubuntu.com/security/CVE-2025-37817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mcb: fix a double free bug in chameleon_parse_gdd() In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev' would be released in mcb_device_register() via put_device(). Thus, goto 'err' label and free 'mdev' again causes a double free. Just return if mcb_device_register() fails.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37819", "url": "https://ubuntu.com/security/CVE-2025-37819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode() With ACPI in place, gicv2m_get_fwnode() is registered with the pci subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 This is easily reproducible on a Juno board with ACPI boot. Retain the function for later use.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37820", "url": "https://ubuntu.com/security/CVE-2025-37820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen-netfront: handle NULL returned by xdp_convert_buff_to_frame() The function xdp_convert_buff_to_frame() may return NULL if it fails to correctly convert the XDP buffer into an XDP frame due to memory constraints, internal errors, or invalid data. Failing to check for NULL may lead to a NULL pointer dereference if the result is used later in processing, potentially causing crashes, data corruption, or undefined behavior. On XDP redirect failure, the associated page must be released explicitly if it was previously retained via get_page(). Failing to do so may result in a memory leak, as the pages reference count is not decremented.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37886", "url": "https://ubuntu.com/security/CVE-2025-37886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: make wait_context part of q_info Make the wait_context a full part of the q_info struct rather than a stack variable that goes away after pdsc_adminq_post() is done so that the context is still available after the wait loop has given up. There was a case where a slow development firmware caused the adminq request to time out, but then later the FW finally finished the request and sent the interrupt. The handler tried to complete_all() the completion context that had been created on the stack in pdsc_adminq_post() but no longer existed. This caused bad pointer usage, kernel crashes, and much wailing and gnashing of teeth.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37887", "url": "https://ubuntu.com/security/CVE-2025-37887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the \"devlink dev info\" devlink command. This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array. Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37823", "url": "https://ubuntu.com/security/CVE-2025-37823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37988", "url": "https://ubuntu.com/security/CVE-2025-37988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount() Normally do_lock_mount(path, _) is locking a mountpoint pinned by *path and at the time when matching unlock_mount() unlocks that location it is still pinned by the same thing. Unfortunately, for 'beneath' case it's no longer that simple - the object being locked is not the one *path points to. It's the mountpoint of path->mnt. The thing is, without sufficient locking ->mnt_parent may change under us and none of the locks are held at that point. The rules are \t* mount_lock stabilizes m->mnt_parent for any mount m. \t* namespace_sem stabilizes m->mnt_parent, provided that m is mounted. \t* if either of the above holds and refcount of m is positive, we are guaranteed the same for refcount of m->mnt_parent. namespace_sem nests inside inode_lock(), so do_lock_mount() has to take inode_lock() before grabbing namespace_sem. It does recheck that path->mnt is still mounted in the same place after getting namespace_sem, and it does take care to pin the dentry. It is needed, since otherwise we might end up with racing mount --move (or umount) happening while we were getting locks; in that case dentry would no longer be a mountpoint and could've been evicted on memory pressure along with its inode - not something you want when grabbing lock on that inode. However, pinning a dentry is not enough - the matching mount is also pinned only by the fact that path->mnt is mounted on top it and at that point we are not holding any locks whatsoever, so the same kind of races could end up with all references to that mount gone just as we are about to enter inode_lock(). If that happens, we are left with filesystem being shut down while we are holding a dentry reference on it; results are not pretty. What we need to do is grab both dentry and mount at the same time; that makes inode_lock() safe *and* avoids the problem with fs getting shut down under us. After taking namespace_sem we verify that path->mnt is still mounted (which stabilizes its ->mnt_parent) and check that it's still mounted at the same place. From that point on to the matching namespace_unlock() we are guaranteed that mount/dentry pair we'd grabbed are also pinned by being the mountpoint of path->mnt, so we can quietly drop both the dentry reference (as the current code does) and mnt one - it's OK to do under namespace_sem, since we are not dropping the final refs. That solves the problem on do_lock_mount() side; unlock_mount() also has one, since dentry is guaranteed to stay pinned only until the namespace_unlock(). That's easy to fix - just have inode_unlock() done earlier, while it's still pinned by mp->m_dentry.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37824", "url": "https://ubuntu.com/security/CVE-2025-37824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL pointer dereference in tipc_mon_reinit_self() syzbot reported: tipc: Node number set to 1055423674 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 There is a racing condition between workqueue created when enabling bearer and another thread created when disabling bearer right after that as follow: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37989", "url": "https://ubuntu.com/security/CVE-2025-37989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: leds: fix memory leak A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code. The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound. This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer. Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37828", "url": "https://ubuntu.com/security/CVE-2025-37828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort() A race can occur between the MCQ completion path and the abort handler: once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash. Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed. This is similar to the fix in commit 74736103fb41 (\"scsi: ufs: core: Fix ufshcd_abort_one racing issue\"). This is found by our static analysis tool KNighter.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37829", "url": "https://ubuntu.com/security/CVE-2025-37829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37830", "url": "https://ubuntu.com/security/CVE-2025-37830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scmi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37831", "url": "https://ubuntu.com/security/CVE-2025-37831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. apple_soc_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37938", "url": "https://ubuntu.com/security/CVE-2025-37938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Verify event formats that have \"%*p..\" The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory. The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses \"%*p..\" the verifier will ignore it, and that could be dangerous. Cover this case as well. Also add to the sample code a use case of \"%*pbl\".", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-39989", "url": "https://ubuntu.com/security/CVE-2025-39989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mce: use is_copy_from_user() to determine copy-from-user context Patch series \"mm/hwpoison: Fix regressions in memory failure handling\", v4. ## 1. What am I trying to do: This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space ## 2. What is the expected outcome and why - For copyin case: Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space. - For instr case: If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage. ## 3. What actually happens and why - For copyin case: kernel panic since v5.17 Commit 4c132d1d844a (\"x86/futex: Remove .fixup usage\") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user(). - For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. ### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a \"real\" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A. Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison). ## Why user process is killed for instr case Commit 046545a661af (\"mm/hwpoison: fix error page recovered but reported \"not ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-22026", "url": "https://ubuntu.com/security/CVE-2025-22026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-37836", "url": "https://ubuntu.com/security/CVE-2025-37836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix reference leak in pci_register_host_bridge() If device_register() fails, call put_device() to give up the reference to avoid a memory leak, per the comment at device_register(). Found by code review. [bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37846", "url": "https://ubuntu.com/security/CVE-2025-37846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: mops: Do not dereference src reg for a set operation The source register is not used for SET* and reading it can result in a UBSAN out-of-bounds array access error, specifically when the MOPS exception is taken from a SET* sequence with XZR (reg 31) as the source. Architecturally this is the only case where a src/dst/size field in the ESR can be reported as 31. Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the use of pt_regs_read_reg() prevented the out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37942", "url": "https://ubuntu.com/security/CVE-2025-37942", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37856", "url": "https://ubuntu.com/security/CVE-2025-37856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: harden block_group::bg_list against list_del() races As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly. However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry. Otherwise we risk the following interleaving (bg_list refcount in parens) T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1) list_del_init(&bg->bg_list); (1) list_move_tail (1) btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1) Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37861", "url": "https://ubuntu.com/security/CVE-2025-37861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37744", "url": "https://ubuntu.com/security/CVE-2025-37744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix memory leak in ath12k_pci_remove() Kmemleak reported this error: unreferenced object 0xffff1c165cec3060 (size 32): comm \"insmod\", pid 560, jiffies 4296964570 (age 235.596s) backtrace: [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0 [<000000001203b155>] kmalloc_trace+0x40/0x88 [<0000000028adc9c8>] _request_firmware+0xb8/0x608 [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80 [<000000005011a682>] local_pci_probe+0x48/0xd0 [<00000000077cd295>] pci_device_probe+0xb4/0x200 [<0000000087184c94>] really_probe+0x150/0x2c0 The firmware memory was allocated in ath12k_pci_probe(), but not freed in ath12k_pci_remove() in case ATH12K_FLAG_QMI_FAIL bit is set. So call ath12k_fw_unmap() to free the memory. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37745", "url": "https://ubuntu.com/security/CVE-2025-37745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM: hibernate: Avoid deadlock in hibernate_compressor_param_set() syzbot reported a deadlock in lock_system_sleep() (see below). The write operation to \"/sys/module/hibernate/parameters/compressor\" conflicts with the registration of ieee80211 device, resulting in a deadlock when attempting to acquire system_transition_mutex under param_lock. To avoid this deadlock, change hibernate_compressor_param_set() to use mutex_trylock() for attempting to acquire system_transition_mutex and return -EBUSY when it fails. Task flags need not be saved or adjusted before calling mutex_trylock(&system_transition_mutex) because the caller is not going to end up waiting for this mutex and if it runs concurrently with system suspend in progress, it will be frozen properly when it returns to user space. syzbot report: syz-executor895/5833 is trying to acquire lock: ffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, at: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56 but task is already holding lock: ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: kernel_param_lock kernel/params.c:607 [inline] ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: param_attr_store+0xe6/0x300 kernel/params.c:586 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (param_lock){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [inline] rate_control_alloc net/mac80211/rate.c:266 [inline] ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558 init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910 do_one_initcall+0x128/0x700 init/main.c:1257 do_initcall_level init/main.c:1319 [inline] do_initcalls init/main.c:1335 [inline] do_basic_setup init/main.c:1354 [inline] kernel_init_freeable+0x5c7/0x900 init/main.c:1568 kernel_init+0x1c/0x2b0 init/main.c:1457 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #2 (rtnl_mutex){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 wg_pm_notification drivers/net/wireguard/device.c:80 [inline] wg_pm_notification+0x49/0x180 drivers/net/wireguard/device.c:64 notifier_call_chain+0xb7/0x410 kernel/notifier.c:85 notifier_call_chain_robust kernel/notifier.c:120 [inline] blocking_notifier_call_chain_robust kernel/notifier.c:345 [inline] blocking_notifier_call_chain_robust+0xc9/0x170 kernel/notifier.c:333 pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102 snapshot_open+0x189/0x2b0 kernel/power/user.c:77 misc_open+0x35a/0x420 drivers/char/misc.c:179 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x735/0x1c40 fs/open.c:956 vfs_open+0x82/0x3f0 fs/open.c:1086 do_open fs/namei.c:3830 [inline] path_openat+0x1e88/0x2d80 fs/namei.c:3989 do_filp_open+0x20c/0x470 fs/namei.c:4016 do_sys_openat2+0x17a/0x1e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [inline] __do_sys_openat fs/open.c:1459 [inline] __se_sys_openat fs/open.c:1454 [inline] __x64_sys_openat+0x175/0x210 fs/open.c:1454 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #1 ((pm_chain_head).rwsem){++++}-{4:4}: down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 blocking_notifier_call_chain_robust kerne ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37945", "url": "https://ubuntu.com/security/CVE-2025-37945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY DSA has 2 kinds of drivers: 1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz 2. Those who don't: all others. The above methods should be optional. For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on. Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered: \tWARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && \t\tphydev->state != PHY_UP); because the PHY state machine is running. It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user. The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs. mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 (\"phylib: fix PAL state machine restart on resume\"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible. This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming mac_managed_pm is set correctly, a quick search indicates the following other drivers might be affected: $ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/prestera_main.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/altera/altera_tse_main.c drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c drivers/net/ethernet/meta/fbnic/fbnic_phylink.c drivers/net/ethernet/tehuti/tn40_phy.c drivers/net/ethernet/mscc/ocelot_net.c Make the existing conditions dependent on the PHY device having a phydev->phy_link_change() implementation equal to the default phy_link_change() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylink_phy_change() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phy_link_change() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test. Thus, for the situation where the PM is not managed b ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37759", "url": "https://ubuntu.com/security/CVE-2025-37759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: fix handling recovery & reissue in ublk_abort_queue() Commit 8284066946e6 (\"ublk: grab request reference when the request is handled by userspace\") doesn't grab request reference in case of recovery reissue. Then the request can be requeued & re-dispatch & failed when canceling uring command. If it is one zc request, the request can be freed before io_uring returns the zc buffer back, then cause kernel panic: [ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 126.773657] #PF: supervisor read access in kernel mode [ 126.774052] #PF: error_code(0x0000) - not-present page [ 126.774455] PGD 0 P4D 0 [ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI [ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full) [ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 [ 126.776275] Workqueue: iou_exit io_ring_exit_work [ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv] Fixes it by always grabbing request reference for aborting the request.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23140", "url": "https://ubuntu.com/security/CVE-2025-23140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released. However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq(). [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-22126", "url": "https://ubuntu.com/security/CVE-2025-22126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix mddev uaf while iterating all_mddevs list While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex. Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-37765", "url": "https://ubuntu.com/security/CVE-2025-37765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix ttm_bo_delayed_delete oops Fix an oops in ttm_bo_delayed_delete which results from dererencing a dangling pointer: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216 Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024 Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290 Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc FS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 The cause of this is: - drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo. - nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo. - nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete. - ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault. Fix this by moving the drm_prime_gem_destroy call from nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will be run after ttm_bo_delayed_delete.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37766", "url": "https://ubuntu.com/security/CVE-2025-37766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37767", "url": "https://ubuntu.com/security/CVE-2025-37767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37768", "url": "https://ubuntu.com/security/CVE-2025-37768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37769", "url": "https://ubuntu.com/security/CVE-2025-37769", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm/smu11: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE. (cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71)", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37770", "url": "https://ubuntu.com/security/CVE-2025-37770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37771", "url": "https://ubuntu.com/security/CVE-2025-37771", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37772", "url": "https://ubuntu.com/security/CVE-2025-37772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix workqueue crash in cma_netevent_work_handler struct rdma_cm_id has member \"struct work_struct net_work\" that is reused for enqueuing cma_netevent_work_handler()s onto cma_wq. Below crash[1] can occur if more than one call to cma_netevent_callback() occurs in quick succession, which further enqueues cma_netevent_work_handler()s for the same rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cma_netevent_callback() and the 2nd INIT_WORK would overwrite the 1st work item (for the same rdma_cm_id), despite grabbing id_table_lock during enqueue. Also drgn analysis [2] indicates the work item was likely overwritten. Fix this by moving the INIT_WORK() to __rdma_create_id(), so that it doesn't race with any existing queue_work() or its worker thread. [1] Trimmed crash stack: ============================================= BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Call Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 ============================================= [2] drgn crash analysis: >>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9) Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168\tstrscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); >>> trace[8][\"work\"] *(struct work_struct *)0xffff92577d0a21d8 = { \t.data = (atomic_long_t){ \t\t.counter = (s64)536870912, <=== Note \t}, \t.entry = (struct list_head){ \t\t.next = (struct list_head *)0xffff924d075924c0, \t\t.prev = (struct list_head *)0xffff924d075924c0, \t}, \t.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, } Suspicion is that pwq is NULL: >>> trace[8][\"pwq\"] (struct pool_workqueue *) In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work); and get_work_pwq() is: static struct pool_workqueue *get_work_pwq(struct work_struct *work) { \tunsigned long data = atomic_long_read(&work->data); \tif (data & WORK_STRUCT_PWQ) \t\treturn work_struct_pwq(data); \telse \t\treturn NULL; } WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4) But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168\tstrscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37773", "url": "https://ubuntu.com/security/CVE-2025-37773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: add filesystem context source name check In certain scenarios, for example, during fuzz testing, the source name may be NULL, which could lead to a kernel panic. Therefore, an extra check for the source name should be added.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37775", "url": "https://ubuntu.com/security/CVE-2025-37775", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix the warning from __kernel_write_iter [ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280 This patch doesn't allow writing to directory.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37778", "url": "https://ubuntu.com/security/CVE-2025-37778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37863", "url": "https://ubuntu.com/security/CVE-2025-37863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: don't allow datadir only In theory overlayfs could support upper layer directly referring to a data layer, but there's no current use case for this. Originally, when data-only layers were introduced, this wasn't allowed, only introduced by the \"datadir+\" feature, but without actually handling this case, resulting in an Oops. Fix by disallowing datadir without lowerdir.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37780", "url": "https://ubuntu.com/security/CVE-2025-37780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: Prevent the use of too small fid syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1] The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handle. Here, fh_len is used to indirectly confirm that the value of handle_bytes is greater than 3 before accessing parent_block. [1] BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37781", "url": "https://ubuntu.com/security/CVE-2025-37781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: cros-ec-tunnel: defer probe if parent EC is not present When i2c-cros-ec-tunnel and the EC driver are built-in, the EC parent device will not be found, leading to NULL pointer dereference. That can also be reproduced by unbinding the controller driver and then loading i2c-cros-ec-tunnel module (or binding the device). [ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 271.998215] #PF: supervisor read access in kernel mode [ 272.003351] #PF: error_code(0x0000) - not-present page [ 272.008485] PGD 0 P4D 0 [ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI [ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5 [ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC [ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021 [ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel] [ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9 [ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282 [ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000 [ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00 [ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000 [ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000 [ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10 [ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000 [ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0 [ 272.129155] Call Trace: [ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110 [ 272.137985] platform_probe+0x69/0xa0 [ 272.141652] really_probe+0x152/0x310 [ 272.145318] __driver_probe_device+0x77/0x110 [ 272.149678] driver_probe_device+0x1e/0x190 [ 272.153864] __driver_attach+0x10b/0x1e0 [ 272.157790] ? driver_attach+0x20/0x20 [ 272.161542] bus_for_each_dev+0x107/0x150 [ 272.165553] bus_add_driver+0x15d/0x270 [ 272.169392] driver_register+0x65/0x110 [ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698] [ 272.182617] do_one_initcall+0x110/0x350 [ 272.186543] ? security_kernfs_init_security+0x49/0xd0 [ 272.191682] ? __kernfs_new_node+0x1b9/0x240 [ 272.195954] ? security_kernfs_init_security+0x49/0xd0 [ 272.201093] ? __kernfs_new_node+0x1b9/0x240 [ 272.205365] ? kernfs_link_sibling+0x105/0x130 [ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0 [ 272.214773] ? kernfs_activate+0x57/0x70 [ 272.218699] ? kernfs_add_one+0x118/0x160 [ 272.222710] ? __kernfs_create_file+0x71/0xa0 [ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110 [ 272.232033] ? internal_create_group+0x453/0x4a0 [ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0 [ 272.241355] ? __free_frozen_pages+0x1dc/0x420 [ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0 [ 272.250505] ? load_module+0x1509/0x16f0 [ 272.254431] do_init_module+0x60/0x230 [ 272.258181] __se_sys_finit_module+0x27a/0x370 [ 272.262627] do_syscall_64+0x6a/0xf0 [ 272.266206] ? do_syscall_64+0x76/0xf0 [ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90 [ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 272.279887] RIP: 0033:0x7b9309168d39 [ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8 [ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37979", "url": "https://ubuntu.com/security/CVE-2025-37979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix sc7280 lpass potential buffer overflow Case values introduced in commit 5f78e1fb7a3e (\"ASoC: qcom: Add driver support for audioreach solution\") cause out of bounds access in arrays of sc7280 driver data (e.g. in case of RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()). Redefine LPASS_MAX_PORTS to consider the maximum possible port id for q6dsp as sc7280 driver utilizes some of those values. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37784", "url": "https://ubuntu.com/security/CVE-2025-37784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ti: icss-iep: Fix possible NULL pointer dereference for perout request The ICSS IEP driver tracks perout and pps enable state with flags. Currently when disabling pps and perout signals during icss_iep_exit(), results in NULL pointer dereference for perout. To fix the null pointer dereference issue, the icss_iep_perout_enable_hw function can be modified to directly clear the IEP CMP registers when disabling PPS or PEROUT, without referencing the ptp_perout_request structure, as its contents are irrelevant in this case.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37786", "url": "https://ubuntu.com/security/CVE-2025-37786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After \"complete\" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37864", "url": "https://ubuntu.com/security/CVE-2025-37864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as commit b117e1e8a86d (\"net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del\"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack. It seems counter-productive to block that path by implementing shim .ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from running, although we could do that. Accepting that cleanup is necessary seems to be the only option. Especially since we appear to be coming back at this from a different angle as well. Russell King is noticing that the WARN_ON() triggers even for VLANs: https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/ What happens in the bug report above is that dsa_port_do_vlan_del() fails, then the VLAN entry lingers on, and then we warn on unbind and leak it. This is not a straight revert of the blamed commit, but we now add an informational print to the kernel log (to still have a way to see that bugs exist), and some extra comments gathered from past years' experience, to justify the logic.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37865", "url": "https://ubuntu.com/security/CVE-2025-37865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported Russell King reports that on the ZII dev rev B, deleting a bridge VLAN from a user port fails with -ENOENT: https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/ This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(), which tries to find an MST entry in &chip->msts associated with the SID, but fails and returns -ENOENT as such. But we know that this chip does not support MST at all, so that is not surprising. The question is why does the guard in mv88e6xxx_mst_put() not exit early: \tif (!sid) \t\treturn 0; And the answer seems to be simple: the sid comes from vlan.sid which supposedly was previously populated by mv88e6xxx_vtu_get(). But some chip->info->ops->vtu_getnext() implementations do not populate vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case, later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is just residual stack memory. Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge VLAN mapped to the default MSTI. For some chips, SID 0 is valid and installed by mv88e6xxx_stu_setup(). A chip which does not support the STU would implicitly only support mapping all VLANs to the default MSTI, so although SID 0 is not valid, it would be sufficient, if we were to zero-initialize the vlan structure, to fix the bug, due to the coincidence that a test for vlan.sid == 0 already exists and leads to the same (correct) behavior. Another option which would be sufficient would be to add a test for mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one which already exists in mv88e6xxx_mst_get(). But that placement means the caller will have to dereference vlan.sid, which means it will access uninitialized memory, which is not nice even if it ignores it later. So we end up making both modifications, in order to not rely just on the sid == 0 coincidence, but also to avoid having uninitialized structure fields which might get temporarily accessed.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37787", "url": "https://ubuntu.com/security/CVE-2025-37787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registered Russell King reports that a system with mv88e6xxx dereferences a NULL pointer when unbinding this driver: https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/ The crash seems to be in devlink_region_destroy(), which is not NULL tolerant but is given a NULL devlink global region pointer. At least on some chips, some devlink regions are conditionally registered since the blamed commit, see mv88e6xxx_setup_devlink_regions_global(): \t\tif (cond && !cond(chip)) \t\t\tcontinue; These are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chip does not have an STU or PVT, it should crash like this. To fix the issue, avoid unregistering those regions which are NULL, i.e. were skipped at mv88e6xxx_setup_devlink_regions_global() time.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37788", "url": "https://ubuntu.com/security/CVE-2025-37788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path In the for loop used to allocate the loc_array and bmap for each port, a memory leak is possible when the allocation for loc_array succeeds, but the allocation for bmap fails. This is because when the control flow goes to the label free_eth_finfo, only the allocations starting from (i-1)th iteration are freed. Fix that by freeing the loc_array in the bmap allocation error path.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37874", "url": "https://ubuntu.com/security/CVE-2025-37874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix memory leak in ngbe_probe() error path When ngbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent error paths after ngbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when ngbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init().", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37789", "url": "https://ubuntu.com/security/CVE-2025-37789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix nested key length validation in the set() action It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37980", "url": "https://ubuntu.com/security/CVE-2025-37980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix resource leak in blk_register_queue() error path When registering a queue fails after blk_mq_sysfs_register() is successful but the function later encounters an error, we need to clean up the blk_mq_sysfs resources. Add the missing blk_mq_sysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37790", "url": "https://ubuntu.com/security/CVE-2025-37790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Set SOCK_RCU_FREE Bind lookup runs under RCU, so ensure that a socket doesn't go away in the middle of a lookup.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37875", "url": "https://ubuntu.com/security/CVE-2025-37875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igc: fix PTM cycle trigger logic Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction. The issue can be reproduced with the following: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: \"ioctl PTP_OFFSET_PRECISE: Connection timed out\" when the PTM transaction fails This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM. The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle. When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump. With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37792", "url": "https://ubuntu.com/security/CVE-2025-37792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: Prevent potential NULL dereference The btrtl_initialize() function checks that rtl_load_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch: drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37867", "url": "https://ubuntu.com/security/CVE-2025-37867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Silence oversized kvmalloc() warning syzkaller triggered an oversized kvmalloc() warning. Silence it by adding __GFP_NOWARN. syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37793", "url": "https://ubuntu.com/security/CVE-2025-37793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, avs_component_probe() does not check for this case, which results in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37982", "url": "https://ubuntu.com/security/CVE-2025-37982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: fix memory leak in wl1251_tx_work The skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup fails with a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37794", "url": "https://ubuntu.com/security/CVE-2025-37794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Purge vif txq in ieee80211_do_stop() After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point).", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37796", "url": "https://ubuntu.com/security/CVE-2025-37796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x: fix use after free access in at76_disconnect The memory pointed to by priv is freed at the end of at76_delete_device function (using ieee80211_free_hw). But the code then accesses the udev field of the freed object to put the USB device. This may also lead to a memory leak of the usb device. Fix this by using udev from interface.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-23141", "url": "https://ubuntu.com/security/CVE-2025-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where \"accepting\" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37940", "url": "https://ubuntu.com/security/CVE-2025-37940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add cond_resched() to ftrace_graph_set_hash() When the kernel contains a large number of functions that can be traced, the loop in ftrace_graph_set_hash() may take a lot of time to execute. This may trigger the softlockup watchdog. Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions. This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37844", "url": "https://ubuntu.com/security/CVE-2025-37844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: avoid NULL pointer dereference in dbg call cifs_server_dbg() implies server to be non-NULL so move call under condition to avoid NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23142", "url": "https://ubuntu.com/security/CVE-2025-23142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: detect and prevent references to a freed transport in sendmsg sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent. There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf(). This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read. This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as \"dead\". In order to do this, the patch restores the \"dead\" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e (\"sctp: remove the dead field of sctp_transport\"). Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process. If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send. The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23144", "url": "https://ubuntu.com/security/CVE-2025-23144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable().", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37892", "url": "https://ubuntu.com/security/CVE-2025-37892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: inftlcore: Add error check for inftl_read_oob() In INFTL_findwriteunit(), the return value of inftl_read_oob() need to be checked. A proper implementation can be found in INFTL_deleteblock(). The status will be set as SECTOR_IGNORE to break from the while-loop correctly if the inftl_read_oob() fails.", "cve_priority": "low", "cve_public_date": "2025-05-20 11:15:00 UTC" }, { "cve": "CVE-2025-23145", "url": "https://ubuntu.com/security/CVE-2025-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix NULL pointer in can_accept_new_subflow When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL. Call trace: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons. Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fixes this issue by moving the 'subflow_req->msk' under the `own_req == true` conditional. Note that the !msk check in subflow_hmac_valid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23146", "url": "https://ubuntu.com/security/CVE-2025-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: ene-kb3930: Fix a potential NULL pointer dereference The off_gpios could be NULL. Add missing check in the kb3930_probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f (\"backlight: hx8357: Fix potential NULL pointer dereference\"). This was detected by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37839", "url": "https://ubuntu.com/security/CVE-2025-37839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: remove wrong sb->s_sequence check Journal emptiness is not determined by sb->s_sequence == 0 but rather by sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a valid transaction ID so the check can spuriously trigger. Remove the invalid WARN_ON.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23147", "url": "https://ubuntu.com/security/CVE-2025-23147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: Add NULL pointer check in i3c_master_queue_ibi() The I3C master driver may receive an IBI from a target device that has not been probed yet. In such cases, the master calls `i3c_master_queue_ibi()` to queue an IBI work task, leading to \"Unable to handle kernel read from unreadable memory\" and resulting in a kernel panic. Typical IBI handling flow: 1. The I3C master scans target devices and probes their respective drivers. 2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`. 3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver’s IBI handler task. However, since target device events are asynchronous to the I3C probe sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`, leading to a kernel panic. Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing an uninitialized `dev->ibi`, ensuring stability.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23148", "url": "https://ubuntu.com/security/CVE-2025-23148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe() soc_dev_attr->revision could be NULL, thus, a pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 (\"ice: Fix some null pointer dereference issues in ice_ptp.c\"). This issue is found by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23149", "url": "https://ubuntu.com/security/CVE-2025-23149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: do not start chip while suspended Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can lead to a spurious tpm_chip_start() call: [35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] [35985.503863] ? __warn+0xd4/0x260 [35985.503868] ? __i2c_transfer+0xbe/0x810 [35985.503874] ? report_bug+0xf3/0x210 [35985.503882] ? handle_bug+0x63/0xb0 [35985.503887] ? exc_invalid_op+0x16/0x50 [35985.503892] ? asm_exc_invalid_op+0x16/0x20 [35985.503904] ? __i2c_transfer+0xbe/0x810 [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0 [35985.503920] tpm_cr50_i2c_read+0x8e/0x120 [35985.503928] tpm_cr50_request_locality+0x75/0x170 [35985.503935] tpm_chip_start+0x116/0x160 [35985.503942] tpm_try_get_ops+0x57/0x90 [35985.503948] tpm_find_get_ops+0x26/0xd0 [35985.503955] tpm_get_random+0x2d/0x80 Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in such a failure case.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23150", "url": "https://ubuntu.com/security/CVE-2025-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one error in do_split Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split. BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The following loop is located right above 'if' statement. for (i = count-1; i >= 0; i--) { \t/* is more than half of this entry in 2nd half of the block? */ \tif (size + map[i].size/2 > blocksize/2) \t\tbreak; \tsize += map[i].size; \tmove++; } 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23151", "url": "https://ubuntu.com/security/CVE-2025-23151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Fix race between unprepare and queue_buf A client driver may use mhi_unprepare_from_transfer() to quiesce incoming data during the client driver's tear down. The client driver might also be processing data at the same time, resulting in a call to mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs after mhi_unprepare_from_transfer() has torn down the channel, a panic will occur due to an invalid dereference leading to a page fault. This occurs because mhi_gen_tre() does not verify the channel state after locking it. Fix this by having mhi_gen_tre() confirm the channel state is valid, or return error to avoid accessing deinitialized data. [mani: added stable tag]", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23156", "url": "https://ubuntu.com/security/CVE-2025-23156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi_parser: refactor hfi packet parsing logic words_count denotes the number of words in total payload, while data points to payload of various property within it. When words_count reaches last word, data can access memory beyond the total payload. This can lead to OOB access. With this patch, the utility api for handling individual properties now returns the size of data consumed. Accordingly remaining bytes are calculated before parsing the payload, thereby eliminates the OOB access possibilities.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23157", "url": "https://ubuntu.com/security/CVE-2025-23157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi_parser: add check to avoid out of bound access There is a possibility that init_codecs is invoked multiple times during manipulated payload from video firmware. In such case, if codecs_count can get incremented to value more than MAX_CODEC_NUM, there can be OOB access. Reset the count so that it always starts from beginning.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37840", "url": "https://ubuntu.com/security/CVE-2025-37840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: brcmnand: fix PM resume warning Fixed warning on PM resume as shown below caused due to uninitialized struct nand_operation that checks chip select field : WARN_ON(op->cs >= nanddev_ntargets(&chip->base) [ 14.588522] ------------[ cut here ]------------ [ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8 [ 14.588553] Modules linked in: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16 [ 14.588590] Tainted: [W]=WARN [ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree) [ 14.588598] Call trace: [ 14.588604] dump_backtrace from show_stack+0x18/0x1c [ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c [ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c [ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c [ 14.588653] r5:c08d40b0 r4:c1003cb0 [ 14.588656] dump_stack from __warn+0x84/0xe4 [ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194 [ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000 [ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8 [ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048 [ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150 [ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040 [ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54 [ 14.588735] r5:00000010 r4:c0840a50 [ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c [ 14.588757] dpm_run_callback from device_resume+0xc0/0x324 [ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010 [ 14.588779] device_resume from dpm_resume+0x130/0x160 [ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0 [ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20 [ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414 [ 14.588826] r4:00000010 [ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8 [ 14.588848] r5:c228a414 r4:00000000 [ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc [ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000 [ 14.588871] r4:00000003 [ 14.588874] pm_suspend from state_store+0x74/0xd0 [ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003 [ 14.588892] state_store from kobj_attr_store+0x1c/0x28 [ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250 [ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c [ 14.588936] r5:c3502900 r4:c0d92a48 [ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0 [ 14.588956] r5:c3502900 r4:c3501f40 [ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420 [ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00 [ 14.588983] r4:c042a88c [ 14.588987] vfs_write from ksys_write+0x74/0xe4 [ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00 [ 14.589008] r4:c34f7f00 [ 14.589011] ksys_write from sys_write+0x10/0x14 [ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004 [ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c [ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0) [ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001 [ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78 [ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8 [ 14.589065] ---[ end trace 0000000000000000 ]--- The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, when doing PM resume operation in compliance with the controller support for single die nand chip. Switching from nand_reset_op() to nan ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37849", "url": "https://ubuntu.com/security/CVE-2025-37849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.", "cve_priority": "high", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23158", "url": "https://ubuntu.com/security/CVE-2025-23158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: add check to handle incorrect queue size qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23159", "url": "https://ubuntu.com/security/CVE-2025-23159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: add a check to handle OOB in sfr region sfr->buf_size is in shared memory and can be modified by malicious user. OOB write is possible when the size is made higher than actual sfr data buffer. Cap the size to allocated size for such cases.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23160", "url": "https://ubuntu.com/security/CVE-2025-23160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37850", "url": "https://ubuntu.com/security/CVE-2025-37850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config() With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line: \tdo_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm])); due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero. This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero. Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section [ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37851", "url": "https://ubuntu.com/security/CVE-2025-37851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: Add 'plane' value check Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB of the enum parameter plane. The value of this parameter is initialized in dss_init_overlays and in the current state of the code it cannot take this value so it's not a real problem. For the purposes of defensive coding it wouldn't be superfluous to check the parameter value, because some functions down the call stack process this value correctly and some not. For example, in dispc_ovl_setup_global_alpha it may lead to buffer overflow. Add check for this value. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23161", "url": "https://ubuntu.com/security/CVE-2025-23161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type The access to the PCI config space via pci_ops::read and pci_ops::write is a low-level hardware access. The functions can be accessed with disabled interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this purpose. A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in the same context as the pci_lock. Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with interrupts disabled. This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90 [bigeasy: reword commit message] Tested-off-by: Luis Claudio R. Goncalves [kwilczynski: commit log] [bhelgaas: add back report info from https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37852", "url": "https://ubuntu.com/security/CVE-2025-37852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() Add error handling to propagate amdgpu_cgs_create_device() failures to the caller. When amdgpu_cgs_create_device() fails, release hwmgr and return -ENOMEM to prevent null pointer dereference. [v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37853", "url": "https://ubuntu.com/security/CVE-2025-37853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: debugfs hang_hws skip GPU with MES debugfs hang_hws is used by GPU reset test with HWS, for MES this crash the kernel with NULL pointer access because dqm->packet_mgr is not setup for MES path. Skip GPU with MES for now, MES hang_hws debugfs interface will be supported later.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37854", "url": "https://ubuntu.com/security/CVE-2025-37854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix mode1 reset crash issue If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM. There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash. To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23163", "url": "https://ubuntu.com/security/CVE-2025-23163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vlan: don't propagate flags on open With the device instance lock, there is now a possibility of a deadlock: [ 1.211455] ============================================ [ 1.211571] WARNING: possible recursive locking detected [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted [ 1.211823] -------------------------------------------- [ 1.211936] ip/184 is trying to acquire lock: [ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0 [ 1.212207] [ 1.212207] but task is already holding lock: [ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.212487] [ 1.212487] other info that might help us debug this: [ 1.212626] Possible unsafe locking scenario: [ 1.212626] [ 1.212751] CPU0 [ 1.212815] ---- [ 1.212871] lock(&dev->lock); [ 1.212944] lock(&dev->lock); [ 1.213016] [ 1.213016] *** DEADLOCK *** [ 1.213016] [ 1.213143] May be due to missing lock nesting notation [ 1.213143] [ 1.213294] 3 locks held by ip/184: [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0 [ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0 [ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.213895] [ 1.213895] stack backtrace: [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 1.213994] Call Trace: [ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0 [ 1.214000] print_deadlock_bug+0x28b/0x2a0 [ 1.214020] lock_acquire+0xea/0x2a0 [ 1.214027] __mutex_lock+0xbf/0xd40 [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev [ 1.214042] __dev_open+0x145/0x270 [ 1.214046] __dev_change_flags+0xb0/0x1e0 [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0 [ 1.214058] notifier_call_chain+0x78/0x120 [ 1.214062] netif_open+0x6d/0x90 [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0 [ 1.214066] bond_enslave+0x64c/0x1230 [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0 [ 1.214077] do_setlink+0x516/0x13b0 [ 1.214094] rtnl_newlink+0xaba/0xb80 [ 1.214132] rtnetlink_rcv_msg+0x440/0x490 [ 1.214144] netlink_rcv_skb+0xeb/0x120 [ 1.214150] netlink_unicast+0x1f9/0x320 [ 1.214153] netlink_sendmsg+0x346/0x3f0 [ 1.214157] __sock_sendmsg+0x86/0xb0 [ 1.214160] ____sys_sendmsg+0x1c8/0x220 [ 1.214164] ___sys_sendmsg+0x28f/0x2d0 [ 1.214179] __x64_sys_sendmsg+0xef/0x140 [ 1.214184] do_syscall_64+0xec/0x1d0 [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 1.214191] RIP: 0033:0x7f2d1b4a7e56 Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down) When we enslave the lower device (netdevsim0) which has a vlan, we propagate vlan's allmuti/promisc flags during ndo_open. This causes (re)locking on of the real_dev. Propagate allmulti/promisc on flags change, not on the open. There is a slight semantics change that vlans that are down now propagate the flags, but this seems unlikely to result in the real issues. Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37857", "url": "https://ubuntu.com/security/CVE-2025-37857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix array overflow in st_setup() Change the array size to follow parms size instead of a fixed value.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37738", "url": "https://ubuntu.com/security/CVE-2025-37738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: ignore xattrs past end Once inside 'ext4_xattr_inode_dec_ref_all' we should ignore xattrs entries past the 'end' entry. This fixes the following KASAN reported issue: ================================================================== BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 Read of size 4 at addr ffff888012c120c4 by task repro/2065 CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x1fd/0x300 ? tcp_gro_dev_warn+0x260/0x260 ? _printk+0xc0/0x100 ? read_lock_is_recursive+0x10/0x10 ? irq_work_queue+0x72/0xf0 ? __virt_addr_valid+0x17b/0x4b0 print_address_description+0x78/0x390 print_report+0x107/0x1f0 ? __virt_addr_valid+0x17b/0x4b0 ? __virt_addr_valid+0x3ff/0x4b0 ? __phys_addr+0xb5/0x160 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 kasan_report+0xcc/0x100 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ? ext4_xattr_delete_inode+0xd30/0xd30 ? __ext4_journal_ensure_credits+0x5f0/0x5f0 ? __ext4_journal_ensure_credits+0x2b/0x5f0 ? inode_update_timestamps+0x410/0x410 ext4_xattr_delete_inode+0xb64/0xd30 ? ext4_truncate+0xb70/0xdc0 ? ext4_expand_extra_isize_ea+0x1d20/0x1d20 ? __ext4_mark_inode_dirty+0x670/0x670 ? ext4_journal_check_start+0x16f/0x240 ? ext4_inode_is_fast_symlink+0x2f2/0x3a0 ext4_evict_inode+0xc8c/0xff0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 ? do_raw_spin_unlock+0x53/0x8a0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 evict+0x4ac/0x950 ? proc_nr_inodes+0x310/0x310 ? trace_ext4_drop_inode+0xa2/0x220 ? _raw_spin_unlock+0x1a/0x30 ? iput+0x4cb/0x7e0 do_unlinkat+0x495/0x7c0 ? try_break_deleg+0x120/0x120 ? 0xffffffff81000000 ? __check_object_size+0x15a/0x210 ? strncpy_from_user+0x13e/0x250 ? getname_flags+0x1dc/0x530 __x64_sys_unlinkat+0xc8/0xf0 do_syscall_64+0x65/0x110 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x434ffd Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8 RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107 RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001 The buggy address belongs to the object at ffff888012c12000 which belongs to the cache filp of size 360 The buggy address is located 196 bytes inside of freed 360-byte region [ffff888012c12000, ffff888012c12168) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12 head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x40(head|node=0|zone=0) page_type: f5(slab) raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000 head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888012c12180: fc fc fc fc fc fc fc fc fc ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37739", "url": "https://ubuntu.com/security/CVE-2025-37739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks() syzbot reports an UBSAN issue as below: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10 index 18446744073709550692 is out of range for type '__le32[5]' (aka 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [inline] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [inline] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f238798cde9 index 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long) In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to access .i_nid[-924], it means both offset[0] and level should zero. The possible case should be in f2fs_do_truncate_blocks(), we try to truncate inode size to zero, however, dn.ofs_in_node is zero and dn.node_page is not an inode page, so it fails to truncate inode page, and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result in this issue. \tif (dn.ofs_in_node || IS_INODE(dn.node_page)) { \t\tf2fs_truncate_data_blocks_range(&dn, count); \t\tfree_from += count; \t} I guess the reason why dn.node_page is not an inode page could be: there are multiple nat entries share the same node block address, once the node block address was reused, f2fs_get_node_page() may load a non-inode block. Let's add a sanity check for such condition to avoid out-of-bounds access issue.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37943", "url": "https://ubuntu.com/security/CVE-2025-37943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath12k_dp_rx_h_undecap_nwifi function for DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially resulting in invalid data access and memory corruption. Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37740", "url": "https://ubuntu.com/security/CVE-2025-37740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add sanity check for agwidth in dbMount The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG. To avoid this issue, add a check for agwidth in dbAllocAG.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37741", "url": "https://ubuntu.com/security/CVE-2025-37741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Prevent copying of nlink with value 0 from disk inode syzbot report a deadlock in diFree. [1] When calling \"ioctl$LOOP_SET_STATUS64\", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated. When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree(). To avoid this, first check the nlink value of dinode before setting iag inode. [1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted -------------------------------------------- syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index])); *** DEADLOCK *** May be due to missing lock nesting notation 5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669 stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37858", "url": "https://ubuntu.com/security/CVE-2025-37858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Prevent integer overflow in AG size calculation The JFS filesystem calculates allocation group (AG) size using 1 << l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB aggregates on 32-bit systems), this 32-bit shift operation causes undefined behavior and improper AG sizing. On 32-bit architectures: - Left-shifting 1 by 32+ bits results in 0 due to integer overflow - This creates invalid AG sizes (0 or garbage values) in sbi->bmap->db_agsize - Subsequent block allocations would reference invalid AG structures - Could lead to: - Filesystem corruption during extend operations - Kernel crashes due to invalid memory accesses - Security vulnerabilities via malformed on-disk structures Fix by casting to s64 before shifting: bmp->db_agsize = (s64)1 << l2agsize; This ensures 64-bit arithmetic even on 32-bit architectures. The cast matches the data type of db_agsize (s64) and follows similar patterns in JFS block calculation code. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37742", "url": "https://ubuntu.com/security/CVE-2025-37742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of imap allocated in the diMount() function syzbot reports that hex_dump_to_buffer is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276 diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876 jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156 evict+0x723/0xd10 fs/inode.c:796 iput_final fs/inode.c:1946 [inline] iput+0x97b/0xdb0 fs/inode.c:1972 txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733 kthread+0x6b9/0xef0 kernel/kthread.c:464 ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] __kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320 kmalloc_noprof include/linux/slab.h:901 [inline] diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105 jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176 jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523 get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636 get_tree_bdev+0x37/0x50 fs/super.c:1659 jfs_get_tree+0x34/0x40 fs/jfs/super.c:635 vfs_get_tree+0xb1/0x5a0 fs/super.c:1814 do_new_mount+0x71f/0x15e0 fs/namespace.c:3560 path_mount+0x742/0x1f10 fs/namespace.c:3887 do_mount fs/namespace.c:3900 [inline] __do_sys_mount fs/namespace.c:4111 [inline] __se_sys_mount+0x71f/0x800 fs/namespace.c:4088 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4088 x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ===================================================== The reason is that imap is not properly initialized after memory allocation. It will cause the snprintf() function to write uninitialized data into linebuf within hex_dump_to_buffer(). Fix this by using kzalloc instead of kmalloc to clear its content at the beginning in diMount().", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37859", "url": "https://ubuntu.com/security/CVE-2025-37859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: page_pool: avoid infinite loop to schedule delayed worker We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1]. Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally. This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry(). [1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37862", "url": "https://ubuntu.com/security/CVE-2025-37862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: pidff: Fix null pointer dereference in pidff_find_fields This function triggered a null pointer dereference if used to search for a report that isn't implemented on the device. This happened both for optional and required reports alike. The same logic was applied to pidff_find_special_field and although pidff_init_fields should return an error earlier if one of the required reports is missing, future modifications could change this logic and resurface this possible null pointer dereference again. LKML bug report: https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37841", "url": "https://ubuntu.com/security/CVE-2025-37841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pm: cpupower: bench: Prevent NULL dereference on malloc failure If malloc returns NULL due to low memory, 'config' pointer can be NULL. Add a check to prevent NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37748", "url": "https://ubuntu.com/security/CVE-2025-37748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group Currently, mtk_iommu calls during probe iommu_device_register before the hw_list from driver data is initialized. Since iommu probing issue fix, it leads to NULL pointer dereference in mtk_iommu_device_group when hw_list is accessed with list_first_entry (not null safe). So, change the call order to ensure iommu_device_register is called after the driver data are initialized.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37749", "url": "https://ubuntu.com/security/CVE-2025-37749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ppp: Add bound checking for skb data on ppp_sync_txmung Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets. When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef➤ p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { \ttype = 0x1, \tver = 0x1, \tcode = 0x0, \tsid = 0x2, length = 0x0, \ttag = 0xffff8880371cdb96 } from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 \"4\", data = 0xffff88803346f416 \":\\377\", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, it is not safe to access data[2]. [pabeni@redhat.com: fixed subj typo]", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37754", "url": "https://ubuntu.com/security/CVE-2025-37754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/huc: Fix fence not released on early probe errors HuC delayed loading fence, introduced with commit 27536e03271da (\"drm/i915/huc: track delayed HuC load with a fence\"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel: <4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] ... <4> [309.733806] ---[ end trace 0000000000000000 ]--- That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup step to driver release path. (cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37755", "url": "https://ubuntu.com/security/CVE-2025-37755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: handle page_pool_dev_alloc_pages error page_pool_dev_alloc_pages could return NULL. There was a WARN_ON(!page) but it would still proceed to use the NULL pointer and then crash. This is similar to commit 001ba0902046 (\"net: fec: handle page_pool_dev_alloc_pages error\"). This is found by our static analysis tool KNighter.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37757", "url": "https://ubuntu.com/security/CVE-2025-37757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix memory leak in tipc_link_xmit In case the backlog transmit queue for system-importance messages is overloaded, tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to memory leak and failure when a skb is allocated. This commit fixes this issue by purging the skb list before tipc_link_xmit() returns.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37758", "url": "https://ubuntu.com/security/CVE-2025-37758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe() devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does not check for this case, which can result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37801", "url": "https://ubuntu.com/security/CVE-2025-37801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-imx: Add check for spi_imx_setupxfer() Add check for the return value of spi_imx_setupxfer(). spi_imx->rx and spi_imx->tx function pointer can be NULL when spi_imx_setupxfer() return error, and make NULL pointer dereference. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: 0x0 spi_imx_pio_transfer+0x50/0xd8 spi_imx_transfer_one+0x18c/0x858 spi_transfer_one_message+0x43c/0x790 __spi_pump_transfer_message+0x238/0x5d4 __spi_sync+0x2b0/0x454 spi_write_then_read+0x11c/0x200", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-39946", "url": "https://ubuntu.com/security/CVE-2025-39946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: make sure to abort the stream if headers are bogus Normally we wait for the socket to buffer up the whole record before we service it. If the socket has a tiny buffer, however, we read out the data sooner, to prevent connection stalls. Make sure that we abort the connection when we find out late that the record is actually invalid. Retrying the parsing is fine in itself but since we copy some more data each time before we parse we can overflow the allocated skb space. Constructing a scenario in which we're under pressure without enough data in the socket to parse the length upfront is quite hard. syzbot figured out a way to do this by serving us the header in small OOB sends, and then filling in the recvbuf with a large normal send. Make sure that tls_rx_msg_size() aborts strp, if we reach an invalid record there's really no way to recover.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-38584", "url": "https://ubuntu.com/security/CVE-2025-38584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: Fix pd UAF once and for all There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-40019", "url": "https://ubuntu.com/security/CVE-2025-40019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: essiv - Check ssize for decryption and in-place encryption Move the ssize check to the start in essiv_aead_crypt so that it's also checked for decryption and in-place encryption.", "cve_priority": "medium", "cve_public_date": "2025-10-24 12:15:00 UTC" }, { "cve": "CVE-2025-38561", "url": "https://ubuntu.com/security/CVE-2025-38561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix Preauh_HashValue race condition If client send multiple session setup requests to ksmbd, Preauh_HashValue race condition could happen. There is no need to free sess->Preauh_HashValue at session setup phase. It can be freed together with session at connection termination phase.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-39698", "url": "https://ubuntu.com/security/CVE-2025-39698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/futex: ensure io_futex_wait() cleans up properly on failure The io_futex_data is allocated upfront and assigned to the io_kiocb async_data field, but the request isn't marked with REQ_F_ASYNC_DATA at that point. Those two should always go together, as the flag tells io_uring whether the field is valid or not. Additionally, on failure cleanup, the futex handler frees the data but does not clear ->async_data. Clear the data and the flag in the error path as well. Thanks to Trend Micro Zero Day Initiative and particularly ReDress for reporting this.", "cve_priority": "high", "cve_public_date": "2025-09-05 18:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2138307, 2122531, 2138244, 2137901, 1786013, 2136820, 2137528, 2130244, 2128722, 2131265, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2135716, 2135261, 1928890, 2112357, 2096976, 2012859, 2031531, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2134382, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2132317, 2065369, 2071861, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2131046, 2083800, 2127971, 2102077, 2121997, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722 ], "changes": [ { "cves": [], "log": [ "", " * noble/linux: 6.8.0-100.100 -proposed tracker (LP: #2138307)", "", " * Turbo boost stuck disabled on Clevo PD5x_7xSNC_SND_SNE (LP: #2122531)", " - cpufreq: intel_pstate: Check IDA only before MSR_IA32_PERF_CTL writes", "", " * [noble] write-sealed memfd mappings fail to map read-only (LP: #2138244)", " - SAUCE: Fix read-only mapping of write-sealed pages", "" ], "package": "linux", "version": "6.8.0-100.100", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2138307, 2122531, 2138244 ], "author": "Stefan Bader ", "date": "Tue, 13 Jan 2026 14:56:02 +0100" }, { "cves": [ { "cve": "CVE-2025-39779", "url": "https://ubuntu.com/security/CVE-2025-39779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39759", "url": "https://ubuntu.com/security/CVE-2025-39759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix race between quota disable and quota rescan ioctl There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info->qgroup_tree rbtree. This happens as follows: 1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan(); 2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A); 3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock; 4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free. Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas were already disabled.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39705", "url": "https://ubuntu.com/security/CVE-2025-39705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a Null pointer dereference vulnerability [Why] A null pointer dereference vulnerability exists in the AMD display driver's (DC module) cleanup function dc_destruct(). When display control context (dc->ctx) construction fails (due to memory allocation failure), this pointer remains NULL. During subsequent error handling when dc_destruct() is called, there's no NULL check before dereferencing the perf_trace member (dc->ctx->perf_trace), causing a kernel null pointer dereference crash. [How] Check if dc->ctx is non-NULL before dereferencing. (Updated commit text and removed unnecessary error message) (cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39707", "url": "https://ubuntu.com/security/CVE-2025-39707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities HUBBUB structure is not initialized on DCE hardware, so check if it is NULL to avoid null dereference while accessing amdgpu_dm_capabilities file in debugfs.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39712", "url": "https://ubuntu.com/security/CVE-2025-39712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval Getting / Setting the frame interval using the V4L2 subdev pad ops get_frame_interval/set_frame_interval causes a deadlock, as the subdev state is locked in the [1] but also in the driver itself. In [2] it's described that the caller is responsible to acquire and release the lock in this case. Therefore, acquiring the lock in the driver is wrong. Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval() and mt9m114_ifp_set_frame_interval(). [1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129 [2] Documentation/driver-api/media/v4l2-subdev.rst", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-38686", "url": "https://ubuntu.com/security/CVE-2025-38686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry When UFFDIO_MOVE encounters a migration PMD entry, it proceeds with obtaining a folio and accessing it even though the entry is swp_entry_t. Add the missing check and let split_huge_pmd() handle migration entries. While at it also remove unnecessary folio check. [surenb@google.com: remove extra folio check, per David]", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38703", "url": "https://ubuntu.com/security/CVE-2025-38703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Make dma-fences compliant with the safe access rules Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a sync_fence fd) which will then cause an use- after-free on subsequent access. To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence. For the timeline name we simply make the queue be freed via kfree_rcu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39746", "url": "https://ubuntu.com/security/CVE-2025-39746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: shutdown driver when hardware is unreliable In rare cases, ath10k may lose connection with the PCIe bus due to some unknown reasons, which could further lead to system crashes during resuming due to watchdog timeout: ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardware ath10k_pci 0000:01:00.0: already restarting ath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11 ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11 ieee80211 phy0: PM: **** DPM device timeout **** Call Trace: panic+0x125/0x315 dpm_watchdog_set+0x54/0x54 dpm_watchdog_handler+0x57/0x57 call_timer_fn+0x31/0x13c At this point, all WMI commands will timeout and attempt to restart device. So set a threshold for consecutive restart failures. If the threshold is exceeded, consider the hardware is unreliable and all ath10k operations should be skipped to avoid system crash. fail_cont_count and pending_recovery are atomic variables, and do not involve complex conditional logic. Therefore, even if recovery check and reconfig complete are executed concurrently, the recovery mechanism will not be broken. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39747", "url": "https://ubuntu.com/security/CVE-2025-39747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Add error handling for krealloc in metadata setup Function msm_ioctl_gem_info_set_metadata() now checks for krealloc failure and returns -ENOMEM, avoiding potential NULL pointer dereference. Explicitly avoids __GFP_NOFAIL due to deadlock risks and allocation constraints. Patchwork: https://patchwork.freedesktop.org/patch/661235/", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38704", "url": "https://ubuntu.com/security/CVE-2025-38704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer access In the preparation stage of CPU online, if the corresponding the rdp's->nocb_cb_kthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocb_cb_kthread pointer, but this rdp's->nocb_gp_rdp and rdp's->rdp_gp->nocb_gp_kthread is still valid. This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthread_unpark() will access invalid rdp's->nocb_cb_kthread pointer. This commit therefore use rdp's->nocb_gp_kthread instead of rdp_gp's->nocb_gp_kthread for safety check.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39748", "url": "https://ubuntu.com/security/CVE-2025-39748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38705", "url": "https://ubuntu.com/security/CVE-2025-38705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix null pointer access Writing a string without delimiters (' ', '\\n', '\\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38710", "url": "https://ubuntu.com/security/CVE-2025-38710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38722", "url": "https://ubuntu.com/security/CVE-2025-38722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: habanalabs: fix UAF in export_dmabuf() As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). habanalabs export_dmabuf() calls it and then proceeds to access the objects destroyed on close. In particular, it grabs an extra reference to another struct file that will be dropped as part of ->release() for ours; that \"will be\" is actually \"might have already been\". Fix that by reserving descriptor before anything else and do fd_install() only when everything had been set up. As a side benefit, we no longer have the failure exit with file already created, but reference to underlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet; unlike dma_buf_fd(), fd_install() can't fail.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38732", "url": "https://ubuntu.com/security/CVE-2025-38732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject: don't leak dst refcount for loopback packets recent patches to add a WARN() when replacing skb dst entry found an old bug: WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline] WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline] WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234 [..] Call Trace: nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline] .. This is because blamed commit forgot about loopback packets. Such packets already have a dst_entry attached, even at PRE_ROUTING stage. Instead of checking hook just check if the skb already has a route attached to it.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39766", "url": "https://ubuntu.com/security/CVE-2025-39766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit The following setup can trigger a WARNING in htb_activate due to the condition: !cl->leaf.q->q.qlen tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 \\ htb rate 64bit tc qdisc add dev lo parent 1:1 handle f: \\ cake memlimit 1b ping -I lo -f -c1 -s64 -W0.001 127.0.0.1 This is because the low memlimit leads to a low buffer_limit, which causes packet dropping. However, cake_enqueue still returns NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an empty child qdisc. We should return NET_XMIT_CN when packets are dropped from the same tin and flow. I do not believe return value of NET_XMIT_CN is necessary for packet drops in the case of ack filtering, as that is meant to optimize performance, not to signal congestion.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38734", "url": "https://ubuntu.com/security/CVE-2025-38734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF on smcsk after smc_listen_out() BPF CI testing report a UAF issue: [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: error_code(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ? __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590 The direct cause of this issue is that after smc_listen_out_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows: smc_listen_work | userspace ----------------------------------------------------------------- lock_sock(sk) | smc_listen_out_connected() | | \\- smc_listen_out | | | \\- release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | \\- socket->sk = NULL; /* newclcsock->sk is NULL now */ SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk)) Since smc_listen_out_connected() will not fail, simply swapping the order of the code can easily fix this issue.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-38735", "url": "https://ubuntu.com/security/CVE-2025-38735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: prevent ethtool ops after shutdown A crash can occur if an ethtool operation is invoked after shutdown() is called. shutdown() is invoked during system shutdown to stop DMA operations without performing expensive deallocations. It is discouraged to unregister the netdev in this path, so the device may still be visible to userspace and kernel helpers. In gve, shutdown() tears down most internal data structures. If an ethtool operation is dispatched after shutdown(), it will dereference freed or NULL pointers, leading to a kernel panic. While graceful shutdown normally quiesces userspace before invoking the reboot syscall, forced shutdowns (as observed on GCP VMs) can still trigger this path. Fix by calling netif_device_detach() in shutdown(). This marks the device as detached so the ethtool ioctl handler will skip dispatching operations to the driver.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39673", "url": "https://ubuntu.com/security/CVE-2025-39673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix race conditions in ppp_fill_forward_path ppp_fill_forward_path() has two race conditions: 1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic. 2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels. Fix these by using a lockless RCU approach: - Use list_first_or_null_rcu() to safely test and access the first list entry. - Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal. - Check for a NULL pch->chan before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39770", "url": "https://ubuntu.com/security/CVE-2025-39770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM When performing Generic Segmentation Offload (GSO) on an IPv6 packet that contains extension headers, the kernel incorrectly requests checksum offload if the egress device only advertises NETIF_F_IPV6_CSUM feature, which has a strict contract: it supports checksum offload only for plain TCP or UDP over IPv6 and explicitly does not support packets with extension headers. The current GSO logic violates this contract by failing to disable the feature for packets with extension headers, such as those used in GREoIPv6 tunnels. This violation results in the device being asked to perform an operation it cannot support, leading to a `skb_warn_bad_offload` warning and a collapse of network throughput. While device TSO/USO is correctly bypassed in favor of software GSO for these packets, the GSO stack must be explicitly told not to request checksum offload. Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4 in gso_features_check if the IPv6 header contains extension headers to compute checksum in software. The exception is a BIG TCP extension, which, as stated in commit 68e068cabd2c6c53 (\"net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets\"): \"The feature is only enabled on devices that support BIG TCP TSO. The header is only present for PF_PACKET taps like tcpdump, and not transmitted by physical devices.\" kernel log output (truncated): WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140 ... Call Trace: skb_checksum_help+0x12a/0x1f0 validate_xmit_skb+0x1a3/0x2d0 validate_xmit_skb_list+0x4f/0x80 sch_direct_xmit+0x1a2/0x380 __dev_xmit_skb+0x242/0x670 __dev_queue_xmit+0x3fc/0x7f0 ip6_finish_output2+0x25e/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel] ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre] dev_hard_start_xmit+0x63/0x1c0 __dev_queue_xmit+0x6d0/0x7f0 ip6_finish_output2+0x214/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 inet6_csk_xmit+0xeb/0x150 __tcp_transmit_skb+0x555/0xa80 tcp_write_xmit+0x32a/0xe90 tcp_sendmsg_locked+0x437/0x1110 tcp_sendmsg+0x2f/0x50 ... skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00 skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00 skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00 skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00 skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9 skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01 skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39675", "url": "https://ubuntu.com/security/CVE-2025-39675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session() The function mod_hdcp_hdcp1_create_session() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference. Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null. This is similar to the commit c3e9826a2202 (\"drm/amd/display: Add null pointer check for get_first_active_display()\"). (cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39772", "url": "https://ubuntu.com/security/CVE-2025-39772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/hisilicon/hibmc: fix the hibmc loaded failed bug When hibmc loaded failed, the driver use hibmc_unload to free the resource, but the mutexes in mode.config are not init, which will access an NULL pointer. Just change goto statement to return, because hibnc_hw_init() doesn't need to free anything.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38676", "url": "https://ubuntu.com/security/CVE-2025-38676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Avoid stack buffer overflow from kernel cmdline While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of \"acpiid\" if the \"str\" argument is maximum length.", "cve_priority": "medium", "cve_public_date": "2025-08-26 13:15:00 UTC" }, { "cve": "CVE-2025-39676", "url": "https://ubuntu.com/security/CVE-2025-39676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla4xxx: Prevent a potential error pointer dereference The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error, but qla4xxx_ep_connect() returns error pointers. Propagating the error pointers will lead to an Oops in the caller, so change the error pointers to NULL.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39773", "url": "https://ubuntu.com/security/CVE-2025-39773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix soft lockup in br_multicast_query_expired() When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > \t/sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a (\"net: bridge: mcast: add and enforce query interval minimum\"), add check for the query interval maximum to fix this issue.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39679", "url": "https://ubuntu.com/security/CVE-2025-39679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor(). When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39681", "url": "https://ubuntu.com/security/CVE-2025-39681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper Since 923f3a2b48bd (\"x86/resctrl: Query LLC monitoring properties once during boot\") resctrl_cpu_detect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code. This triggers a division by zero fault during early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale. Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ]", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39687", "url": "https://ubuntu.com/security/CVE-2025-39687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: as73211: Ensure buffer holes are zeroed Given that the buffer is copied to a kfifo that ultimately user space can read, ensure we zero it.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39683", "url": "https://ubuntu.com/security/CVE-2025-39683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Limit access to parser->buffer when trace_get_user failed When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered: BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165 CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39801", "url": "https://ubuntu.com/security/CVE-2025-39801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Remove WARN_ON for device endpoint command timeouts This commit addresses a rarely observed endpoint command timeout which causes kernel panic due to warn when 'panic_on_warn' is enabled and unnecessary call trace prints when 'panic_on_warn' is disabled. It is seen during fast software-controlled connect/disconnect testcases. The following is one such endpoint command timeout that we observed: 1. Connect ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd 2. Disconnect ========== ->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmd In the issue scenario, in Exynos platforms, we observed that control transfers for the previous connect have not yet been completed and end transfer command sent as a part of the disconnect sequence and processing of USB_ENDPOINT_HALT feature request from the host timeout. This maybe an expected scenario since the controller is processing EP commands sent as a part of the previous connect. It maybe better to remove WARN_ON in all places where device endpoint commands are sent to avoid unnecessary kernel panic due to warn.", "cve_priority": "medium", "cve_public_date": "2025-09-15 13:15:00 UTC" }, { "cve": "CVE-2025-39684", "url": "https://ubuntu.com/security/CVE-2025-39684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl() syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernel buffer is allocated to hold `insn->n` samples (each of which is an `unsigned int`). For some instruction types, `insn->n` samples are copied back to user-space, unless an error code is being returned. The problem is that not all the instruction handlers that need to return data to userspace fill in the whole `insn->n` samples, so that there is an information leak. There is a similar syzbot report for `do_insnlist_ioctl()`, although it does not have a reproducer for it at the time of writing. One culprit is `insn_rw_emulate_bits()` which is used as the handler for `INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have a specific handler for that instruction, but do have an `INSN_BITS` handler. For `INSN_READ` it only fills in at most 1 sample, so if `insn->n` is greater than 1, the remaining `insn->n - 1` samples copied to userspace will be uninitialized kernel data. Another culprit is `vm80xx_ai_insn_read()` in the \"vm80xx\" driver. It never returns an error, even if it fails to fill the buffer. Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure that uninitialized parts of the allocated buffer are zeroed before handling each instruction. Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fix replaced the call to `kmalloc_array()` with `kcalloc()`, but it is not always necessary to clear the whole buffer.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39685", "url": "https://ubuntu.com/security/CVE-2025-39685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: pcl726: Prevent invalid irq number The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob. Added an interrupt number check to prevent users from passing in an irq number that was too large. If `it->options[1]` is 31, then `1 << it->options[1]` is still invalid because it shifts a 1-bit into the sign bit (which is UB in C). Possible solutions include reducing the upper bound on the `it->options[1]` value to 30 or lower, or using `1U << it->options[1]`. The old code would just not attempt to request the IRQ if the `options[1]` value were invalid. And it would still configure the device without interrupts even if the call to `request_irq` returned an error. So it would be better to combine this test with the test below.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39686", "url": "https://ubuntu.com/security/CVE-2025-39686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Make insn_rw_emulate_bits() do insn->n samples The `insn_rw_emulate_bits()` function is used as a default handler for `INSN_READ` instructions for subdevices that have a handler for `INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a default handler for `INSN_WRITE` instructions for subdevices that have a handler for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the `INSN_READ` or `INSN_WRITE` instruction handling with a constructed `INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE` instructions are supposed to be able read or write multiple samples, indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currently only handles a single sample. For `INSN_READ`, the comedi core will copy `insn->n` samples back to user-space. (That triggered KASAN kernel-infoleak errors when `insn->n` was greater than 1, but that is being fixed more generally elsewhere in the comedi core.) Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or return an error, to conform to the general expectation for `INSN_READ` and `INSN_WRITE` handlers.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39689", "url": "https://ubuntu.com/security/CVE-2025-39689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Also allocate and copy hash for reading of filter files Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs. Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39691", "url": "https://ubuntu.com/security/CVE-2025-39691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/buffer: fix use-after-free when call bh_read() helper There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio \t do_mpage_readpage \t ntfs_get_block_vbo \t bh_read \t submit_bh \t wait_on_buffer(bh); \t blk_complete_reqs \t\t\t\t scsi_io_completion \t\t\t\t scsi_end_request \t\t\t\t blk_update_request \t\t\t\t end_bio_bh_io_sync \t\t\t\t\t end_buffer_read_sync \t\t\t\t\t __end_buffer_read_notouch \t\t\t\t\t unlock_buffer wait_on_buffer(bh);--> return will return to caller \t\t\t\t\t put_bh \t\t\t\t\t --> trigger stack-out-of-bounds In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun. If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch().", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39692", "url": "https://ubuntu.com/security/CVE-2025-39692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy() We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()! Otherwise already existing connections try to use smb_direct_wq as a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39788", "url": "https://ubuntu.com/security/CVE-2025-39788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE On Google gs101, the number of UTP transfer request slots (nutrs) is 32, and in this case the driver ends up programming the UTRL_NEXUS_TYPE incorrectly as 0. This is because the left hand side of the shift is 1, which is of type int, i.e. 31 bits wide. Shifting by more than that width results in undefined behaviour. Fix this by switching to the BIT() macro, which applies correct type casting as required. This ensures the correct value is written to UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift warning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int' For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE write.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39693", "url": "https://ubuntu.com/security/CVE-2025-39693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid a NULL pointer dereference [WHY] Although unlikely drm_atomic_get_new_connector_state() or drm_atomic_get_old_connector_state() can return NULL. [HOW] Check returns before dereference. (cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39694", "url": "https://ubuntu.com/security/CVE-2025-39694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Fix SCCB present check Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation. If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping. Fix this by introducing a function that handles the NULL case before address translation.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39776", "url": "https://ubuntu.com/security/CVE-2025-39776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/debug_vm_pgtable: clear page table entries at destroy_args() The mm/debug_vm_pagetable test allocates manually page table entries for the tests it runs, using also its manually allocated mm_struct. That in itself is ok, but when it exits, at destroy_args() it fails to clear those entries with the *_clear functions. The problem is that leaves stale entries. If another process allocates an mm_struct with a pgd at the same address, it may end up running into the stale entry. This is happening in practice on a debug kernel with CONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extra debugging I added (it prints a warning trace if pgtables_bytes goes negative, in addition to the warning at check_mm() function): [ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000 [ 2.539366] kmem_cache info [ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508 [ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e (...) [ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0 [ 2.552816] Modules linked in: [ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY [ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries [ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90 [ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug) [ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a [ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0 [ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001 [ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff [ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000 [ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb [ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0 [ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000 [ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001 [ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760 [ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0 [ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0 [ 2.553199] Call Trace: [ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable) [ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0 [ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570 [ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650 [ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290 [ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0 [ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870 [ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150 [ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50 [ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0 [ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec (...) [ 2.558892] ---[ end trace 0000000000000000 ]--- [ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1 [ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144 Here the modprobe process ended up with an allocated mm_struct from the mm_struct slab that was used before by the debug_vm_pgtable test. That is not a problem, since the mm_stru ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38681", "url": "https://ubuntu.com/security/CVE-2025-38681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd() Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39800", "url": "https://ubuntu.com/security/CVE-2025-39800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: abort transaction on unexpected eb generation at btrfs_copy_root() If we find an unexpected generation for the extent buffer we are cloning at btrfs_copy_root(), we just WARN_ON() and don't error out and abort the transaction, meaning we allow to persist metadata with an unexpected generation. Instead of warning only, abort the transaction and return -EUCLEAN.", "cve_priority": "medium", "cve_public_date": "2025-09-15 13:15:00 UTC" }, { "cve": "CVE-2025-38684", "url": "https://ubuntu.com/security/CVE-2025-38684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: use old 'nbands' while purging unused classes Shuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify() after recent changes from Lion [2]. The problem is: in ets_qdisc_change() we purge unused DWRR queues; the value of 'q->nbands' is the new one, and the cleanup should be done with the old one. The problem is here since my first attempts to fix ets_qdisc_change(), but it surfaced again after the recent qdisc len accounting fixes. Fix it purging idle DWRR queues before assigning a new value of 'q->nbands', so that all purge operations find a consistent configuration: - old 'q->nbands' because it's needed by ets_class_find() - old 'q->nstrict' because it's needed by ets_class_is_strict() BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary) Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021 RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80 Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <48> 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab RSP: 0018:ffffba186009f400 EFLAGS: 00010202 RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004 RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004 R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000 R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000 FS: 00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ets_class_qlen_notify+0x65/0x90 [sch_ets] qdisc_tree_reduce_backlog+0x74/0x110 ets_qdisc_change+0x630/0xa40 [sch_ets] __tc_modify_qdisc.constprop.0+0x216/0x7f0 tc_modify_qdisc+0x7c/0x120 rtnetlink_rcv_msg+0x145/0x3f0 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x245/0x390 netlink_sendmsg+0x21b/0x470 ____sys_sendmsg+0x39d/0x3d0 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x7d/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f2155114084 Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084 RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003 RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0 R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0 [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/ [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-21884", "url": "https://ubuntu.com/security/CVE-2025-21884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: better track kernel sockets lifetime While kernel sockets are dismantled during pernet_operations->exit(), their freeing can be delayed by any tx packets still held in qdisc or device queues, due to skb_set_owner_w() prior calls. This then trigger the following warning from ref_tracker_dir_exit() [1] To fix this, make sure that kernel sockets own a reference on net->passive. Add sk_net_refcnt_upgrade() helper, used whenever a kernel socket is converted to a refcounted one. [1] [ 136.263918][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at [ 136.263918][ T35] sk_alloc+0x2b3/0x370 [ 136.263918][ T35] inet6_create+0x6ce/0x10f0 [ 136.263918][ T35] __sock_create+0x4c0/0xa30 [ 136.263918][ T35] inet_ctl_sock_create+0xc2/0x250 [ 136.263918][ T35] igmp6_net_init+0x39/0x390 [ 136.263918][ T35] ops_init+0x31e/0x590 [ 136.263918][ T35] setup_net+0x287/0x9e0 [ 136.263918][ T35] copy_net_ns+0x33f/0x570 [ 136.263918][ T35] create_new_namespaces+0x425/0x7b0 [ 136.263918][ T35] unshare_nsproxy_namespaces+0x124/0x180 [ 136.263918][ T35] ksys_unshare+0x57d/0xa70 [ 136.263918][ T35] __x64_sys_unshare+0x38/0x40 [ 136.263918][ T35] do_syscall_64+0xf3/0x230 [ 136.263918][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 136.263918][ T35] [ 136.343488][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at [ 136.343488][ T35] sk_alloc+0x2b3/0x370 [ 136.343488][ T35] inet6_create+0x6ce/0x10f0 [ 136.343488][ T35] __sock_create+0x4c0/0xa30 [ 136.343488][ T35] inet_ctl_sock_create+0xc2/0x250 [ 136.343488][ T35] ndisc_net_init+0xa7/0x2b0 [ 136.343488][ T35] ops_init+0x31e/0x590 [ 136.343488][ T35] setup_net+0x287/0x9e0 [ 136.343488][ T35] copy_net_ns+0x33f/0x570 [ 136.343488][ T35] create_new_namespaces+0x425/0x7b0 [ 136.343488][ T35] unshare_nsproxy_namespaces+0x124/0x180 [ 136.343488][ T35] ksys_unshare+0x57d/0xa70 [ 136.343488][ T35] __x64_sys_unshare+0x38/0x40 [ 136.343488][ T35] do_syscall_64+0xf3/0x230 [ 136.343488][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-39701", "url": "https://ubuntu.com/security/CVE-2025-39701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: pfr_update: Fix the driver update version check The security-version-number check should be used rather than the runtime version check for driver updates. Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39702", "url": "https://ubuntu.com/security/CVE-2025-39702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39703", "url": "https://ubuntu.com/security/CVE-2025-39703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net, hsr: reject HSR frame if skb can't hold tag Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG): [ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0 [ 45.402911] Call Trace: [ 45.403105] [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [ 45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116] __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] This issue was found by syzkaller. The panic happens in br_dev_queue_push_xmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skb_push() call, there's not enough headroom and skb_push() panics. The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG). Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers. Alternative fix would be to check for enough headroom before skb_push() in br_dev_queue_push_xmit(). In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network. Further Details: In the reproducer, the following network interface chain is set up: ┌────────────────┐ ┌────────────────┐ │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘ To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39706", "url": "https://ubuntu.com/security/CVE-2025-39706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Destroy KFD debugfs after destroy KFD wq Since KFD proc content was moved to kernel debugfs, we can't destroy KFD debugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq prior to kfd_debugfs_fini to fix a kernel NULL pointer problem. It happens when /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini but kfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry); tries to remove /sys/kernel/debug/kfd/proc/ while /sys/kernel/debug/kfd is already gone. It hangs the kernel by kernel NULL pointer. (cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39709", "url": "https://ubuntu.com/security/CVE-2025-39709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: protect against spurious interrupts during probe Make sure the interrupt handler is initialized before the interrupt is registered. If the IRQ is registered before hfi_create(), it's possible that an interrupt fires before the handler setup is complete, leading to a NULL dereference. This error condition has been observed during system boot on Rb3Gen2.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39710", "url": "https://ubuntu.com/security/CVE-2025-39710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: Add a check for packet size after reading from shared memory Add a check to ensure that the packet size does not exceed the number of available words after reading the packet header from shared memory. This ensures that the size provided by the firmware is safe to process and prevent potential out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39711", "url": "https://ubuntu.com/security/CVE-2025-39711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls Both the ACE and CSI driver are missing a mei_cldev_disable() call in their remove() function. This causes the mei_cl client to stay part of the mei_device->file_list list even though its memory is freed by mei_cl_bus_dev_release() calling kfree(cldev->cl). This leads to a use-after-free when mei_vsc_remove() runs mei_stop() which first removes all mei bus devices calling mei_ace_remove() and mei_csi_remove() followed by mei_cl_bus_dev_release() and then calls mei_cl_all_disconnect() which walks over mei_device->file_list dereferecing the just freed cldev->cl. And mei_vsc_remove() it self is run at shutdown because of the platform_device_unregister(tp->pdev) in vsc_tp_shutdown() When building a kernel with KASAN this leads to the following KASAN report: [ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNED_MODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] ... [ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei [ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc [ 106.635066] platform_remove (drivers/base/platform.c:1424) Add the missing mei_cldev_disable() calls so that the mei_cl gets removed from mei_device->file_list before it is freed to fix this.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39713", "url": "https://ubuntu.com/security/CVE-2025-39713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt() In the interrupt handler rain_interrupt(), the buffer full check on rain->buf_len is performed before acquiring rain->buf_lock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buf_len is concurrently accessed and modified in the work handler rain_irq_work_handler() under the same lock. Multiple interrupt invocations can race, with each reading buf_len before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buf_len beyond its capacity (DATA_SIZE) and causing a buffer overflow. Fix this bug by moving the spin_lock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spin_unlock() is added to the overflow path to correctly release the lock. This possible bug was found by an experimental static analysis tool developed by our team.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39714", "url": "https://ubuntu.com/security/CVE-2025-39714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: Lock resolution while streaming When an program is streaming (ffplay) and another program (qv4l2) changes the TV standard from NTSC to PAL, the kernel crashes due to trying to copy to unmapped memory. Changing from NTSC to PAL increases the resolution in the usbtv struct, but the video plane buffer isn't adjusted, so it overflows. [hverkuil: call vb2_is_busy instead of vb2_is_streaming]", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39715", "url": "https://ubuntu.com/security/CVE-2025-39715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Revise gateway LWS calls to probe user read access We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER). Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39716", "url": "https://ubuntu.com/security/CVE-2025-39716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Revise __get_user() to probe user read access Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call. Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed. Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39781", "url": "https://ubuntu.com/security/CVE-2025-39781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Drop WARN_ON_ONCE() from flush_cache_vmap I have observed warning to occassionally trigger.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39782", "url": "https://ubuntu.com/security/CVE-2025-39782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: prevent softlockup in jbd2_log_do_checkpoint() Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant. jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup. watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20 So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38677", "url": "https://ubuntu.com/security/CVE-2025-38677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-boundary access in dnode page As Jiaming Zhang reported: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x17e/0x800 mm/kasan/report.c:480 kasan_report+0x147/0x180 mm/kasan/report.c:593 data_blkaddr fs/f2fs/f2fs.h:3053 [inline] f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline] f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855 f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195 prepare_write_begin fs/f2fs/data.c:3395 [inline] f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594 generic_perform_write+0x2c7/0x910 mm/filemap.c:4112 f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline] f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x546/0xa90 fs/read_write.c:686 ksys_write+0x149/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is in the corrupted image, there is a dnode has the same node id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to access block address in dnode at offset 934, however it parses the dnode as inode node, so that get_dnode_addr() returns 360, then it tries to access page address from 360 + 934 * 4 = 4096 w/ 4 bytes. To fix this issue, let's add sanity check for node id of all direct nodes during f2fs_get_dnode_of_data().", "cve_priority": "medium", "cve_public_date": "2025-08-30 10:15:00 UTC" }, { "cve": "CVE-2025-39718", "url": "https://ubuntu.com/security/CVE-2025-39718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Validate length in packet header before skb_put() When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put().", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39783", "url": "https://ubuntu.com/security/CVE-2025-39783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix configfs group list head handling Doing a list_del() on the epf_group field of struct pci_epf_driver in pci_epf_remove_cfs() is not correct as this field is a list head, not a list entry. This list_del() call triggers a KASAN warning when an endpoint function driver which has a configfs attribute group is torn down: ================================================================== BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198 Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319 CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONE Hardware name: Radxa ROCK 5B (DT) Call trace: show_stack+0x2c/0x84 (C) dump_stack_lvl+0x70/0x98 print_report+0x17c/0x538 kasan_report+0xb8/0x190 __asan_report_store8_noabort+0x20/0x2c pci_epf_remove_cfs+0x17c/0x198 pci_epf_unregister_driver+0x18/0x30 nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf] __arm64_sys_delete_module+0x264/0x424 invoke_syscall+0x70/0x260 el0_svc_common.constprop.0+0xac/0x230 do_el0_svc+0x40/0x58 el0_svc+0x48/0xdc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ... Remove this incorrect list_del() call from pci_epf_remove_cfs().", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39719", "url": "https://ubuntu.com/security/CVE-2025-39719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: imu: bno055: fix OOB access of hw_xlate array Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c. In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array. By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39787", "url": "https://ubuntu.com/security/CVE-2025-39787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: qcom: mdt_loader: Ensure we don't read past the ELF header When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients. Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. e_phentsize and e_shentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39720", "url": "https://ubuntu.com/security/CVE-2025-39720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix refcount leak causing resource not released When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39721", "url": "https://ubuntu.com/security/CVE-2025-39721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - flush misc workqueue during device shutdown Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded. Since the driver uses a shared workqueue (`qat_misc_wq`) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50 To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded. Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39790", "url": "https://ubuntu.com/security/CVE-2025-39790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Detect events pointing to unexpected TREs When a remote device sends a completion event to the host, it contains a pointer to the consumed TRE. The host uses this pointer to process all of the TREs between it and the host's local copy of the ring's read pointer. This works when processing completion for chained transactions, but can lead to nasty results if the device sends an event for a single-element transaction with a read pointer that is multiple elements ahead of the host's read pointer. For instance, if the host accesses an event ring while the device is updating it, the pointer inside of the event might still point to an old TRE. If the host uses the channel's xfer_cb() to directly free the buffer pointed to by the TRE, the buffer will be double-freed. This behavior was observed on an ep that used upstream EP stack without 'commit 6f18d174b73d (\"bus: mhi: ep: Update read pointer only after buffer is written\")'. Where the device updated the events ring pointer before updating the event contents, so it left a window where the host was able to access the stale data the event pointed to, before the device had the chance to update them. The usual pattern was that the host received an event pointing to a TRE that is not immediately after the last processed one, so it got treated as if it was a chained transaction, processing all of the TREs in between the two read pointers. This commit aims to harden the host by ensuring transactions where the event points to a TRE that isn't local_rp + 1 are chained. [mani: added stable tag and reworded commit message]", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39724", "url": "https://ubuntu.com/security/CVE-2025-39724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39758", "url": "https://ubuntu.com/security/CVE-2025-39758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages Ever since commit c2ff29e99a76 (\"siw: Inline do_tcp_sendpages()\"), we have been doing this: static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset, size_t size) [...] /* Calculate the number of bytes we need to push, for this page * specifically */ size_t bytes = min_t(size_t, PAGE_SIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; /* Set the bvec pointing to the page, with len $bytes */ bvec_set_page(&bvec, page[i], bytes, offset); /* Set the iter to $size, aka the size of the whole sendpages (!!!) */ iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size); try_page_again: lock_sock(sk); /* Sendmsg with $size size (!!!) */ rv = tcp_sendmsg_locked(sk, &msg, size); This means we've been sending oversized iov_iters and tcp_sendmsg calls for a while. This has a been a benign bug because sendpage_ok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in iov_iter behavior between the MSG_SPLICE_PAGES and \"regular\" copy paths: (MSG_SPLICE_PAGES) skb_splice_from_iter iov_iter_extract_pages iov_iter_extract_bvec_pages uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere skb_splice_from_iter gets a \"short\" read (!MSG_SPLICE_PAGES) skb_copy_to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len = iter->count; iterate_bvec ... and we run off the bvecs Fix this by properly setting the iov_iter's byte count, plus sending the correct byte count to tcp_sendmsg_locked.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38679", "url": "https://ubuntu.com/security/CVE-2025-38679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: Fix OOB read due to missing payload bound check Currently, The event_seq_changed() handler processes a variable number of properties sent by the firmware. The number of properties is indicated by the firmware and used to iterate over the payload. However, the payload size is not being validated against the actual message length. This can lead to out-of-bounds memory access if the firmware provides a property count that exceeds the data available in the payload. Such a condition can result in kernel crashes or potential information leaks if memory beyond the buffer is accessed. Fix this by properly validating the remaining size of the payload before each property access and updating bounds accordingly as properties are parsed. This ensures that property parsing is safely bounded within the received message buffer and protects against malformed or malicious firmware behavior.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38680", "url": "https://ubuntu.com/security/CVE-2025-38680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() The buffer length check before calling uvc_parse_format() only ensured that the buffer has at least 3 bytes (buflen > 2), buf the function accesses buffer[3], requiring at least 4 bytes. This can lead to an out-of-bounds read if the buffer has exactly 3 bytes. Fix it by checking that the buffer has at least 4 bytes in uvc_parse_format().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39736", "url": "https://ubuntu.com/security/CVE-2025-39736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock When netpoll is enabled, calling pr_warn_once() while holding kmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock inversion with the netconsole subsystem. This occurs because pr_warn_once() may trigger netpoll, which eventually leads to __alloc_skb() and back into kmemleak code, attempting to reacquire kmemleak_lock. This is the path for the deadlock. mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem \t -> netpoll \t -> __alloc_skb \t\t -> __create_object \t\t -> raw_spin_lock_irqsave(&kmemleak_lock, flags); Fix this by setting a flag and issuing the pr_warn_once() after kmemleak_lock is released.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39737", "url": "https://ubuntu.com/security/CVE-2025-39737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup() A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134] The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000. The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects. As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38683", "url": "https://ubuntu.com/security/CVE-2025-38683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Fix panic during namespace deletion with VF The existing code move the VF NIC to new namespace when NETDEV_REGISTER is received on netvsc NIC. During deletion of the namespace, default_device_exit_batch() >> default_device_exit_net() is called. When netvsc NIC is moved back and registered to the default namespace, it automatically brings VF NIC back to the default namespace. This will cause the default_device_exit_net() >> for_each_netdev_safe loop unable to detect the list end, and hit NULL ptr: [ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0 [ 231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 231.450246] #PF: supervisor read access in kernel mode [ 231.450579] #PF: error_code(0x0000) - not-present page [ 231.450916] PGD 17b8a8067 P4D 0 [ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI [ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY [ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024 [ 231.452692] Workqueue: netns cleanup_net [ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0 [ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00 [ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246 [ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb [ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564 [ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000 [ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340 [ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340 [ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000 [ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0 [ 231.458434] Call Trace: [ 231.458600] [ 231.458777] ops_undo_list+0x100/0x220 [ 231.459015] cleanup_net+0x1b8/0x300 [ 231.459285] process_one_work+0x184/0x340 To fix it, move the ns change to a workqueue, and take rtnl_lock to avoid changing the netdev list when default_device_exit_net() is using it.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38685", "url": "https://ubuntu.com/security/CVE-2025-38685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix vmalloc out-of-bounds write in fast_imageblit This issue triggers when a userspace program does an ioctl FBIOPUT_CON2FBMAP by passing console number and frame buffer number. Ideally this maps console to frame buffer and updates the screen if console is visible. As part of mapping it has to do resize of console according to frame buffer info. if this resize fails and returns from vc_do_resize() and continues further. At this point console and new frame buffer are mapped and sets display vars. Despite failure still it continue to proceed updating the screen at later stages where vc_data is related to previous frame buffer and frame buffer info and display vars are mapped to new frame buffer and eventully leading to out-of-bounds write in fast_imageblit(). This bheviour is excepted only when fg_console is equal to requested console which is a visible console and updates screen with invalid struct references in fbcon_putcs().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39738", "url": "https://ubuntu.com/security/CVE-2025-39738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not allow relocation of partially dropped subvolumes [BUG] There is an internal report that balance triggered transaction abort, with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs] And btrfs check doesn't report anything wrong related to the extent tree. [CAUSE] The cause is a little complex, firstly the extent tree indeed doesn't have the backref for 594526208. The extent tree only have the following two backrefs around that bytenr on-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE But the such missing backref item is not an corruption on disk, as the offending delayed ref belongs to subvolume 934, and that subvolume is being dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229 And that offending tree block 594526208 is inside the dropped range of that subvolume. That explains why there is no backref item for that bytenr and why btrfs check is not reporting anything wrong. But this also shows another problem, as btrfs will do all the orphan subvolume cleanup at a read-write mount. So half-dropped subvolume should not exist after an RW mount, and balance itself is also exclusive to subvolume cleanup, meaning we shouldn't hit a subvolume half-dropped during relocation. The root cause is, there is no orphan item for this subvolume. In fact there are 5 subvolumes from around 2021 that have the same problem. It looks like the original report has some older kernels running, and caused those zombie subvolumes. Thankfully upstream commit 8d488a8c7ba2 (\"btrfs: fix subvolume/snapshot deletion not triggered on mount\") has long fixed the bug. [ENHANCEMENT] For repairing such old fs, btrfs-progs will be enhanced. Considering how delayed the problem will show up (at run delayed ref time) and at that time we have to abort transaction already, it is too late. Instead here we reject any half-dropped subvolume for reloc tree at the earliest time, preventing confusion and extra time wasted on debugging similar bugs.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38687", "url": "https://ubuntu.com/security/CVE-2025-38687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: fix race between polling and detaching syzbot reports a use-after-free in comedi in the below link, which is due to comedi gladly removing the allocated async area even though poll requests are still active on the wait_queue_head inside of it. This can cause a use-after-free when the poll entries are later triggered or removed, as the memory for the wait_queue_head has been freed. We need to check there are no tasks queued on any of the subdevices' wait queues before allowing the device to be detached by the `COMEDI_DEVCONFIG` ioctl. Tasks will read-lock `dev->attach_lock` before adding themselves to the subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl handler by write-locking `dev->attach_lock` before checking that all of the subdevices are safe to be deleted. This includes testing for any sleepers on the subdevices' wait queues. It remains locked until the device has been detached. This requires the `comedi_device_detach()` function to be refactored slightly, moving the bulk of it into new function `comedi_device_detach_locked()`. Note that the refactor of `comedi_device_detach()` results in `comedi_device_cancel_all()` now being called while `dev->attach_lock` is write-locked, which wasn't the case previously, but that does not matter. Thanks to Jens Axboe for diagnosing the problem and co-developing this patch.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39760", "url": "https://ubuntu.com/security/CVE-2025-39760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: config: Prevent OOB read in SS endpoint companion parsing usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size. Fix this up by checking the size first before looking at any of the fields in the descriptor.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38688", "url": "https://ubuntu.com/security/CVE-2025-38688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Prevent ALIGN() overflow When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either. Consolidate the two copies of this code under a single helper. This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39739", "url": "https://ubuntu.com/security/CVE-2025-39739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-qcom: Add SM6115 MDSS compatible Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot: arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed) ------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 \t\t... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38691", "url": "https://ubuntu.com/security/CVE-2025-38691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix uninited ptr deref in block/scsi layout The error occurs on the third attempt to encode extents. When function ext_tree_prepare_commit() reallocates a larger buffer to retry encoding extents, the \"layoutupdate_pages\" page array is initialized only after the retry loop. But ext_tree_free_commitdata() is called on every iteration and tries to put pages in the array, thus dereferencing uninitialized pointers. An additional problem is that there is no limit on the maximum possible buffer_size. When there are too many extents, the client may create a layoutcommit that is larger than the maximum possible RPC size accepted by the server. During testing, we observed two typical scenarios. First, one memory page for extents is enough when we work with small files, append data to the end of the file, or preallocate extents before writing. But when we fill a new large file without preallocating, the number of extents can be huge, and counting the number of written extents in ext_tree_encode_commit() does not help much. Since this number increases even more between unlocking and locking of ext_tree, the reallocated buffer may not be large enough again and again.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39795", "url": "https://ubuntu.com/security/CVE-2025-39795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: avoid possible overflow for chunk_sectors check in blk_stack_limits() In blk_stack_limits(), we check that the t->chunk_sectors value is a multiple of the t->physical_block_size value. However, by finding the chunk_sectors value in bytes, we may overflow the unsigned int which holds chunk_sectors, so change the check to be based on sectors.", "cve_priority": "medium", "cve_public_date": "2025-09-12 16:15:00 UTC" }, { "cve": "CVE-2025-38692", "url": "https://ubuntu.com/security/CVE-2025-38692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: add cluster chain loop check for dir An infinite loop may occur if the following conditions occur due to file system corruption. (1) Condition for exfat_count_dir_entries() to loop infinitely. - The cluster chain includes a loop. - There is no UNUSED entry in the cluster chain. (2) Condition for exfat_create_upcase_table() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and up-case table entry in the cluster chain of the root directory. (3) Condition for exfat_load_bitmap() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and bitmap entry in the cluster chain of the root directory. (4) Condition for exfat_find_dir_entry() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. (5) Condition for exfat_check_dir_empty() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. - All files and sub-directories under the directory are deleted. This commit adds checks to break the above infinite loop.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38693", "url": "https://ubuntu.com/security/CVE-2025-38693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serpar In w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar commit: commit 0ed554fd769a (\"media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()\")", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38694", "url": "https://ubuntu.com/security/CVE-2025-38694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb() In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar issue occurs when access msg[1].buf[0] and msg[1].buf[1]. Similar commit: commit 0ed554fd769a (\"media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()\")", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38695", "url": "https://ubuntu.com/security/CVE-2025-38695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may occur before sli4_hba.hdwqs are allocated. This may result in a null pointer dereference when attempting to take the abts_io_buf_list_lock for the first hardware queue. Fix by adding a null ptr check on phba->sli4_hba.hdwq and early return because this situation means there must have been an error during port initialization.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39742", "url": "https://ubuntu.com/security/CVE-2025-39742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask() The function divides number of online CPUs by num_core_siblings, and later checks the divider by zero. This implies a possibility to get and divide-by-zero runtime error. Fix it by moving the check prior to division. This also helps to save one indentation level.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38696", "url": "https://ubuntu.com/security/CVE-2025-38696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: Don't crash in stack_top() for tasks without ABI or vDSO Not all tasks have an ABI associated or vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL ABI pointer and crash. This can for example happen when using kunit: mips_stack_top+0x28/0xc0 arch_pick_mmap_layout+0x190/0x220 kunit_vm_mmap_init+0xf8/0x138 __kunit_add_resource+0x40/0xa8 kunit_vm_mmap+0x88/0xd8 usercopy_test_init+0xb8/0x240 kunit_try_run_case+0x5c/0x1a8 kunit_generic_run_threadfn_adapter+0x28/0x50 kthread+0x118/0x240 ret_from_kernel_thread+0x14/0x1c Only dereference the ABI point if it is set. The GIC page is also included as it is specific to the vDSO. Also move the randomization adjustment into the same conditional.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38697", "url": "https://ubuntu.com/security/CVE-2025-38697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: upper bound check of tree index in dbAllocAG When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38698", "url": "https://ubuntu.com/security/CVE-2025-38698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Regular file corruption check The reproducer builds a corrupted file on disk with a negative i_size value. Add a check when opening this file to avoid subsequent operation failures.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39743", "url": "https://ubuntu.com/security/CVE-2025-39743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: truncate good inode pages when hard link is 0 The fileset value of the inode copy from the disk by the reproducer is AGGR_RESERVED_I. When executing evict, its hard link number is 0, so its inode pages are not truncated. This causes the bugon to be triggered when executing clear_inode() because nrpages is greater than 0.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38699", "url": "https://ubuntu.com/security/CVE-2025-38699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Double-free fix When the bfad_im_probe() function fails during initialization, the memory pointed to by bfad->im is freed without setting bfad->im to NULL. Subsequently, during driver uninstallation, when the state machine enters the bfad_sm_stopping state and calls the bfad_im_probe_undo() function, it attempts to free the memory pointed to by bfad->im again, thereby triggering a double-free vulnerability. Set bfad->im to NULL if probing fails.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38700", "url": "https://ubuntu.com/security/CVE-2025-38700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown. Fix by setting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38701", "url": "https://ubuntu.com/security/CVE-2025-38701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data() when an inode had the INLINE_DATA_FL flag set but was missing the system.data extended attribute. Since this can happen due to a maiciouly fuzzed file system, we shouldn't BUG, but rather, report it as a corrupted file system. Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii ext4_create_inline_data() and ext4_inline_data_truncate().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38702", "url": "https://ubuntu.com/security/CVE-2025-38702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix potential buffer overflow in do_register_framebuffer() The current implementation may lead to buffer overflow when: 1. Unregistration creates NULL gaps in registered_fb[] 2. All array slots become occupied despite num_registered_fb < FB_MAX 3. The registration loop exceeds array bounds Add boundary check to prevent registered_fb[FB_MAX] access.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39744", "url": "https://ubuntu.com/security/CVE-2025-39744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu: Fix rcu_read_unlock() deadloop due to IRQ work During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up. This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly. irq_exit() __irq_exit_rcu() /* in_hardirq() returns false after this */ preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() \t tick_nohz_stop_sched_tick() \t trace_tick_stop() /* a bpf prog is hooked on this trace point */ \t\t __bpf_trace_tick_stop() \t\t bpf_trace_run2() \t\t\t rcu_read_unlock_special() /* will send a IPI to itself */ \t\t\t irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu); A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch: static inline void tick_irq_exit(void) { +\trcu_read_lock(); +\tWRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); +\trcu_read_unlock(); + [neeraj: Apply Frederic's suggested fix for PREEMPT_RT]", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39761", "url": "https://ubuntu.com/security/CVE-2025-39761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Decrement TID on RX peer frag setup error handling Currently, TID is not decremented before peer cleanup, during error handling path of ath12k_dp_rx_peer_frag_setup(). This could lead to out-of-bounds access in peer->rx_tid[]. Hence, add a decrement operation for TID, before peer cleanup to ensures proper cleanup and prevents out-of-bounds access issues when the RX peer frag setup fails. Found during code review. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39797", "url": "https://ubuntu.com/security/CVE-2025-39797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Duplicate SPI Handling The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses. This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops. According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol. Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable. Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.", "cve_priority": "medium", "cve_public_date": "2025-09-12 16:15:00 UTC" }, { "cve": "CVE-2025-39749", "url": "https://ubuntu.com/security/CVE-2025-39749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu: Protect ->defer_qs_iw_pending from data race On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest. In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally. The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat: ------------------------------------------------------------------------ BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [] __schedule+0x129/0xd70 softirqs last enabled at (0): [] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0 ------------------------------------------------------------------------ The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field. This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39750", "url": "https://ubuntu.com/security/CVE-2025-39750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Correct tid cleanup when tid setup fails Currently, if any error occurs during ath12k_dp_rx_peer_tid_setup(), the tid value is already incremented, even though the corresponding TID is not actually allocated. Proceed to ath12k_dp_rx_peer_tid_delete() starting from unallocated tid, which might leads to freeing unallocated TID and cause potential crash or out-of-bounds access. Hence, fix by correctly decrementing tid before cleanup to match only the successfully allocated TIDs. Also, remove tid-- from failure case of ath12k_dp_rx_peer_frag_setup(), as decrementing the tid before cleanup in loop will take care of this. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38706", "url": "https://ubuntu.com/security/CVE-2025-38706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime() snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39794", "url": "https://ubuntu.com/security/CVE-2025-39794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: tegra: Use I/O memcpy to write to IRAM Kasan crashes the kernel trying to check boundaries when using the normal memcpy.", "cve_priority": "medium", "cve_public_date": "2025-09-12 16:15:00 UTC" }, { "cve": "CVE-2025-39752", "url": "https://ubuntu.com/security/CVE-2025-39752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: rockchip: fix kernel hang during smp initialization In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39763", "url": "https://ubuntu.com/security/CVE-2025-39763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered If a synchronous error is detected as a result of user-space process triggering a 2-bit uncorrected error, the CPU will take a synchronous error exception such as Synchronous External Abort (SEA) on Arm64. The kernel will queue a memory_failure() work which poisons the related page, unmaps the page, and then sends a SIGBUS to the process, so that a system wide panic can be avoided. However, no memory_failure() work will be queued when abnormal synchronous errors occur. These errors can include situations like invalid PA, unexpected severity, no memory failure config support, invalid GUID section, etc. In such a case, the user-space process will trigger SEA again. This loop can potentially exceed the platform firmware threshold or even trigger a kernel hard lockup, leading to a system reboot. Fix it by performing a force kill if no memory_failure() work is queued for synchronous errors. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38707", "url": "https://ubuntu.com/security/CVE-2025-38707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add sanity check for file name The length of the file name should be smaller than the directory entry size.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38708", "url": "https://ubuntu.com/security/CVE-2025-38708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: add missing kref_get in handle_write_conflicts With `two-primaries` enabled, DRBD tries to detect \"concurrent\" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed. In handling \"superseeded\" writes, we forgot a kref_get, resulting in a premature drbd_destroy_device and use after free, and further to kernel crashes with symptoms. Relevance: No one should use DRBD as a random data generator, and apparently all users of \"two-primaries\" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node. Which means that other than for \"test cases\", this code path is never taken in real life. FYI, in DRBD 9, things are handled differently nowadays. We still detect \"write conflicts\", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39753", "url": "https://ubuntu.com/security/CVE-2025-39753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Set .migrate_folio in gfs2_{rgrp,meta}_aops Clears up the warning added in 7ee3647243e5 (\"migrate: Remove call to ->writepage\") that occurs in various xfstests, causing \"something found in dmesg\" failures. [ 341.136573] gfs2_meta_aops does not implement migrate_folio [ 341.136953] WARNING: CPU: 1 PID: 36 at mm/migrate.c:944 move_to_new_folio+0x2f8/0x300", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38711", "url": "https://ubuntu.com/security/CVE-2025-38711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: avoid deadlock when linking with ReplaceIfExists If smb2_create_link() is called with ReplaceIfExists set and the name does exist then a deadlock will happen. ksmbd_vfs_kern_path_locked() will return with success and the parent directory will be locked. ksmbd_vfs_remove_file() will then remove the file. ksmbd_vfs_link() will then be called while the parent is still locked. It will try to lock the same parent and will deadlock. This patch moves the ksmbd_vfs_kern_path_unlock() call to *before* ksmbd_vfs_link() and then simplifies the code, removing the file_present flag variable.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38712", "url": "https://ubuntu.com/security/CVE-2025-38712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file() When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplus_fill_super() assumes that the attributes file is not yet created, which later results in hitting BUG_ON() when hfsplus_create_attributes_file() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38713", "url": "https://ubuntu.com/security/CVE-2025-38713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc(): [ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 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 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38714", "url": "https://ubuntu.com/security/CVE-2025-38714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read() The hfsplus_bnode_read() method can trigger the issue: [ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0 [ 174.854305][ T9784] print_report+0xd0/0x660 [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610 [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854337][ T9784] kasan_report+0xc6/0x100 [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360 [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380 [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10 [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0 [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310 [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0 [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0 [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10 [ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10 [ 174.854436][ T9784] ? __asan_memset+0x23/0x50 [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320 [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10 [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0 [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0 [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10 [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10 [ 174.854525][ T9784] ? down_write+0x148/0x200 [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10 [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0 [ 174.854549][ T9784] do_unlinkat+0x490/0x670 [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10 [ 174.854565][ T9784] ? __might_fault+0xbc/0x130 [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550 [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110 [ 174.854592][ T9784] do_syscall_64+0xc9/0x480 [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasan_save_stack+0x20/0x40 [ 174.880082][ T9784] kasan_save_track+0x14/0x30 [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0 [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550 [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890 [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10 [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520 [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38715", "url": "https://ubuntu.com/security/CVE-2025-38715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: fix slab-out-of-bounds in hfs_bnode_read() This patch introduces is_bnode_offset_valid() method that checks the requested offset value. Also, it introduces check_and_correct_requested_length() method that checks and correct the requested length (if it is necessary). These methods are used in hfs_bnode_read(), hfs_bnode_write(), hfs_bnode_clear(), hfs_bnode_copy(), and hfs_bnode_move() with the goal to prevent the access out of allocated memory and triggering the crash.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38716", "url": "https://ubuntu.com/security/CVE-2025-38716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: fix general protection fault in hfs_find_init() The hfs_find_init() method can trigger the crash if tree pointer is NULL: [ 45.746290][ T9787] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] SMP KAI [ 45.747287][ T9787] KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] [ 45.748716][ T9787] CPU: 2 UID: 0 PID: 9787 Comm: repro Not tainted 6.16.0-rc3 #10 PREEMPT(full) [ 45.750250][ T9787] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 45.751983][ T9787] RIP: 0010:hfs_find_init+0x86/0x230 [ 45.752834][ T9787] Code: c1 ea 03 80 3c 02 00 0f 85 9a 01 00 00 4c 8d 6b 40 48 c7 45 18 00 00 00 00 48 b8 00 00 00 00 00 fc [ 45.755574][ T9787] RSP: 0018:ffffc90015157668 EFLAGS: 00010202 [ 45.756432][ T9787] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff819a4d09 [ 45.757457][ T9787] RDX: 0000000000000008 RSI: ffffffff819acd3a RDI: ffffc900151576e8 [ 45.758282][ T9787] RBP: ffffc900151576d0 R08: 0000000000000005 R09: 0000000000000000 [ 45.758943][ T9787] R10: 0000000080000000 R11: 0000000000000001 R12: 0000000000000004 [ 45.759619][ T9787] R13: 0000000000000040 R14: ffff88802c50814a R15: 0000000000000000 [ 45.760293][ T9787] FS: 00007ffb72734540(0000) GS:ffff8880cec64000(0000) knlGS:0000000000000000 [ 45.761050][ T9787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 45.761606][ T9787] CR2: 00007f9bd8225000 CR3: 000000010979a000 CR4: 00000000000006f0 [ 45.762286][ T9787] Call Trace: [ 45.762570][ T9787] [ 45.762824][ T9787] hfs_ext_read_extent+0x190/0x9d0 [ 45.763269][ T9787] ? submit_bio_noacct_nocheck+0x2dd/0xce0 [ 45.763766][ T9787] ? __pfx_hfs_ext_read_extent+0x10/0x10 [ 45.764250][ T9787] hfs_get_block+0x55f/0x830 [ 45.764646][ T9787] block_read_full_folio+0x36d/0x850 [ 45.765105][ T9787] ? __pfx_hfs_get_block+0x10/0x10 [ 45.765541][ T9787] ? const_folio_flags+0x5b/0x100 [ 45.765972][ T9787] ? __pfx_hfs_read_folio+0x10/0x10 [ 45.766415][ T9787] filemap_read_folio+0xbe/0x290 [ 45.766840][ T9787] ? __pfx_filemap_read_folio+0x10/0x10 [ 45.767325][ T9787] ? __filemap_get_folio+0x32b/0xbf0 [ 45.767780][ T9787] do_read_cache_folio+0x263/0x5c0 [ 45.768223][ T9787] ? __pfx_hfs_read_folio+0x10/0x10 [ 45.768666][ T9787] read_cache_page+0x5b/0x160 [ 45.769070][ T9787] hfs_btree_open+0x491/0x1740 [ 45.769481][ T9787] hfs_mdb_get+0x15e2/0x1fb0 [ 45.769877][ T9787] ? __pfx_hfs_mdb_get+0x10/0x10 [ 45.770316][ T9787] ? find_held_lock+0x2b/0x80 [ 45.770731][ T9787] ? lockdep_init_map_type+0x5c/0x280 [ 45.771200][ T9787] ? lockdep_init_map_type+0x5c/0x280 [ 45.771674][ T9787] hfs_fill_super+0x38e/0x720 [ 45.772092][ T9787] ? __pfx_hfs_fill_super+0x10/0x10 [ 45.772549][ T9787] ? snprintf+0xbe/0x100 [ 45.772931][ T9787] ? __pfx_snprintf+0x10/0x10 [ 45.773350][ T9787] ? do_raw_spin_lock+0x129/0x2b0 [ 45.773796][ T9787] ? find_held_lock+0x2b/0x80 [ 45.774215][ T9787] ? set_blocksize+0x40a/0x510 [ 45.774636][ T9787] ? sb_set_blocksize+0x176/0x1d0 [ 45.775087][ T9787] ? setup_bdev_super+0x369/0x730 [ 45.775533][ T9787] get_tree_bdev_flags+0x384/0x620 [ 45.775985][ T9787] ? __pfx_hfs_fill_super+0x10/0x10 [ 45.776453][ T9787] ? __pfx_get_tree_bdev_flags+0x10/0x10 [ 45.776950][ T9787] ? bpf_lsm_capable+0x9/0x10 [ 45.777365][ T9787] ? security_capable+0x80/0x260 [ 45.777803][ T9787] vfs_get_tree+0x8e/0x340 [ 45.778203][ T9787] path_mount+0x13de/0x2010 [ 45.778604][ T9787] ? kmem_cache_free+0x2b0/0x4c0 [ 45.779052][ T9787] ? __pfx_path_mount+0x10/0x10 [ 45.779480][ T9787] ? getname_flags.part.0+0x1c5/0x550 [ 45.779954][ T9787] ? putname+0x154/0x1a0 [ 45.780335][ T9787] __x64_sys_mount+0x27b/0x300 [ 45.780758][ T9787] ? __pfx___x64_sys_mount+0x10/0x10 [ 45.781232][ T9787] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38718", "url": "https://ubuntu.com/security/CVE-2025-38718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: linearize cloned gso packets in sctp_rcv A cloned head skb still shares these frag skbs in fraglist with the original head skb. It's not safe to access these frag skbs. syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline] and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] This patch fixes it by linearizing cloned gso packets in sctp_rcv().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38721", "url": "https://ubuntu.com/security/CVE-2025-38721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix refcount leak on table dump There is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ... While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone. This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0. This will then block the netns dismantle (or conntrack rmmod) as nf_conntrack_cleanup_net_list() will wait forever. This can be reproduced by running conntrack_resize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nf_conntrack_cleanup_net_list. One fix would to change this to: if (res < 0) { \t\tif (ct != last) \t nf_conntrack_get(&ct->ct_general); But this reference counting isn't needed in the first place. We can just store a cookie value instead. A followup patch will do the same for ctnetlink_exp_dump_table, it looks to me as if this has the same problem and like ctnetlink_dump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38614", "url": "https://ubuntu.com/security/CVE-2025-38614", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: Fix semi-unbounded recursion Ensure that epoll instances can never form a graph deeper than EP_MAX_NESTS+1 links. Currently, ep_loop_check_proc() ensures that the graph is loop-free and does some recursion depth checks, but those recursion depth checks don't limit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed (\"epoll: limit paths\"). Essentially, the current recursion depth check in ep_loop_check_proc() just serves to prevent it from recursing too deeply while checking for loops. A more thorough check is done in reverse_path_check() after the new graph edge has already been created; this checks, among other things, that no paths going upwards from any non-epoll file with a length of more than 5 edges exist. However, this check does not apply to non-epoll files. As a result, it is possible to recurse to a depth of at least roughly 500, tested on v6.15. (I am unsure if deeper recursion is possible; and this may have changed with commit 8c44dac8add7 (\"eventpoll: Fix priority inversion problem\").) To fix it: 1. In ep_loop_check_proc(), note the subtree depth of each visited node, and use subtree depths for the total depth calculation even when a subtree has already been visited. 2. Add ep_get_upwards_depth_proc() for similarly determining the maximum depth of an upwards walk. 3. In ep_loop_check(), use these values to limit the total path length between epoll nodes to EP_MAX_NESTS edges.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-39756", "url": "https://ubuntu.com/security/CVE-2025-39756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Prevent file descriptor table allocations exceeding INT_MAX When sysctl_nr_open is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 This happens because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning when the allocation is not flagged with __GFP_NOWARN. Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647) Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open 2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; } 3. Observe WARNING in dmesg at mm/slub.c:5027 systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that: 1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting 2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations 3. The resulting allocations (>8GB) are impractical and will always fail systemd's algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems, this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors. While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue. Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39798", "url": "https://ubuntu.com/security/CVE-2025-39798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix the setting of capabilities when automounting a new filesystem Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again.", "cve_priority": "medium", "cve_public_date": "2025-09-12 16:15:00 UTC" }, { "cve": "CVE-2025-38724", "url": "https://ubuntu.com/security/CVE-2025-38724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm() Lei Lu recently reported that nfsd4_setclientid_confirm() did not check the return value from get_client_locked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF. Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all. In the case where the unconfirmed client is expiring, just fail and return the result from get_client_locked().", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38730", "url": "https://ubuntu.com/security/CVE-2025-38730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: commit partial buffers on retry Ring provided buffers are potentially only valid within the single execution context in which they were acquired. io_uring deals with this and invalidates them on retry. But on the networking side, if MSG_WAITALL is set, or if the socket is of the streaming type and too little was processed, then it will hang on to the buffer rather than recycle or commit it. This is problematic for two reasons: 1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid. 2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer. Fix this by disallowing partial retries from pinning a provided buffer across multiple executions, if ring provided buffers are used.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38725", "url": "https://ubuntu.com/security/CVE-2025-38725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: asix_devices: add phy_mask for ax88772 mdio bus Without setting phy_mask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phy_polling_mode() in phy_state_machine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoud the issue.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-38728", "url": "https://ubuntu.com/security/CVE-2025-38728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb3: fix for slab out of bounds on mount to ksmbd With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39757", "url": "https://ubuntu.com/security/CVE-2025-39757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 cluster segment descriptors UAC3 class segment descriptors need to be verified whether their sizes match with the declared lengths and whether they fit with the allocated buffer sizes, too. Otherwise malicious firmware may lead to the unexpected OOB accesses.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-38729", "url": "https://ubuntu.com/security/CVE-2025-38729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 power domain descriptors, too UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-40297", "url": "https://ubuntu.com/security/CVE-2025-40297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix use-after-free due to MST port state bypass syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot. [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40256", "url": "https://ubuntu.com/security/CVE-2025-40256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added In commit b441cf3f8c4b (\"xfrm: delete x->tunnel as we delete x\"), I missed the case where state creation fails between full initialization (->init_state has been called) and being inserted on the lists. In this situation, ->init_state has been called, so for IPcomp tunnels, the fallback tunnel has been created and added onto the lists, but the user state never gets added, because we fail before that. The user state doesn't go through __xfrm_state_delete, so we don't call xfrm_state_delete_tunnel for those states, and we end up leaking the FB tunnel. There are several codepaths affected by this: the add/update paths, in both net/key and xfrm, and the migrate code (xfrm_migrate, xfrm_state_migrate). A \"proper\" rollback of the init_state work would probably be doable in the add/update code, but for migrate it gets more complicated as multiple states may be involved. At some point, the new (not-inserted) state will be destroyed, so call xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states will have their fallback tunnel cleaned up during __xfrm_state_delete, which solves the issue that b441cf3f8c4b (and other patches before it) aimed at. All states (including FB tunnels) will be removed from the lists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40215", "url": "https://ubuntu.com/security/CVE-2025-40215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: delete x->tunnel as we delete x The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 (\"xfrm: destroy xfrm_state synchronously on net exit path\") is not complete. We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f (\"tcp: drop secpath at the same time as we currently drop dst\")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state. Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped. A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.", "cve_priority": "medium", "cve_public_date": "2025-12-04 13:15:00 UTC" }, { "cve": "CVE-2025-40214", "url": "https://ubuntu.com/security/CVE-2025-40214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Initialise scc_index in unix_add_edge(). Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c. Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments.", "cve_priority": "high", "cve_public_date": "2025-12-04 13:15:00 UTC" }, { "cve": "CVE-2025-38248", "url": "https://ubuntu.com/security/CVE-2025-38248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: mcast: Fix use-after-free during router port configuration The bridge maintains a global list of ports behind which a multicast router resides. The list is consulted during forwarding to ensure multicast packets are forwarded to these ports even if the ports are not member in the matching MDB entry. When per-VLAN multicast snooping is enabled, the per-port multicast context is disabled on each port and the port is removed from the global router port list: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 1 $ bridge -d mdb show | grep router However, the port can be re-added to the global list even when per-VLAN multicast snooping is enabled: # ip link set dev dummy1 type bridge_slave mcast_router 0 # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 Since commit 4b30ae9adb04 (\"net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions\"), when per-VLAN multicast snooping is enabled, multicast disablement on a port will disable the per-{port, VLAN} multicast contexts and not the per-port one. As a result, a port will remain in the global router port list even after it is deleted. This will lead to a use-after-free [1] when the list is traversed (when adding a new port to the list, for example): # ip link del dev dummy1 # ip link add name dummy2 up master br1 type dummy # ip link set dev dummy2 type bridge_slave mcast_router 2 Similarly, stale entries can also be found in the per-VLAN router port list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN} contexts are disabled on each port and the port is removed from the per-VLAN router port list: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 # ip link add name dummy1 up master br1 type dummy # bridge vlan add vid 2 dev dummy1 # bridge vlan global set vid 2 dev br1 mcast_snooping 1 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 0 $ bridge vlan global show dev br1 vid 2 | grep router However, the port can be re-added to the per-VLAN list even when per-VLAN multicast snooping is disabled: # bridge vlan set vid 2 dev dummy1 mcast_router 0 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 When the VLAN is deleted from the port, the per-{port, VLAN} multicast context will not be disabled since multicast snooping is not enabled on the VLAN. As a result, the port will remain in the per-VLAN router port list even after it is no longer member in the VLAN. This will lead to a use-after-free [2] when the list is traversed (when adding a new port to the list, for example): # ip link add name dummy2 up master br1 type dummy # bridge vlan add vid 2 dev dummy2 # bridge vlan del vid 2 dev dummy1 # bridge vlan set vid 2 dev dummy2 mcast_router 2 Fix these issues by removing the port from the relevant (global or per-VLAN) router port list in br_multicast_port_ctx_deinit(). The function is invoked during port deletion with the per-port multicast context and during VLAN deletion with the per-{port, VLAN} multicast context. Note that deleting the multicast router timer is not enough as it only takes care of the temporary multicast router states (1 or 3) and not the permanent one (2). [1] BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560 Write of size 8 at addr ffff888004a67328 by task ip/384 [...] Call Trace: dump_stack ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38619", "url": "https://ubuntu.com/security/CVE-2025-38619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: j721e-csi2rx: fix list_del corruption If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue. This causes the same buffer to be retried in the next iteration, resulting in a double list_del() and eventual list corruption. Fix this by removing the buffer from the queue before calling vb2_buffer_done() on error. This resolves a crash due to list_del corruption: [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048 [ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428) [ 37.850799] ------------[ cut here ]------------ [ 37.855424] kernel BUG at lib/list_debug.c:65! [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT) [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.914059] sp : ffff800080003db0 [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122 [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0 [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720 [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568 [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d [ 37.988832] Call trace: [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P) [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4 [ 38.001419] udma_vchan_complete+0x1e0/0x344 [ 38.005705] tasklet_action_common+0x118/0x310 [ 38.010163] tasklet_action+0x30/0x3c [ 38.013832] handle_softirqs+0x10c/0x2e0 [ 38.017761] __do_softirq+0x14/0x20 [ 38.021256] ____do_softirq+0x10/0x20 [ 38.024931] call_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] __irq_exit_rcu+0x130/0x15c [ 38.036909] irq_exit_rcu+0x10/0x20 [ 38.040403] el1_interrupt+0x38/0x60 [ 38.043987] el1h_64_irq_handler+0x18/0x24 [ 38.048091] el1h_64_irq+0x6c/0x70 [ 38.051501] default_idle_call+0x34/0xe0 (P) [ 38.055783] do_idle+0x1f8/0x250 [ 38.059021] cpu_startup_entry+0x34/0x3c [ 38.062951] rest_init+0xb4/0xc0 [ 38.066186] console_on_rootfs+0x0/0x6c [ 38.070031] __primary_switched+0x88/0x90 [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000) [ 38.080168] ---[ end trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.092197] SMP: stopping secondary CPUs [ 38.096139] Kernel Offset: disabled [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b [ 38.105202] Memory Limit: none [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38582", "url": "https://ubuntu.com/security/CVE-2025-38582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix double destruction of rsv_qp rsv_qp may be double destroyed in error flow, first in free_mr_init(), and then in hns_roce_exit(). Fix it by moving the free_mr_init() call into hns_roce_v2_init(). list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38585", "url": "https://ubuntu.com/security/CVE-2025-38585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() When gmin_get_config_var() calls efi.get_variable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow: 1. gmin_get_config_var() does not return the proper error code when efi.get_variable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure. 2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates *out_len to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmin_get_var_int() believes the call succeeded. The caller gmin_get_var_int() then performs: - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size - Due to bug #1, thinks call succeeded with len=required_size - Executes val[len] = 0, writing past end of 65-byte stack buffer This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution. Fix the bug by returning proper error codes from gmin_get_config_var() based on EFI status instead of stale 'ret' value. The gmin_get_var_int() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38593", "url": "https://ubuntu.com/security/CVE-2025-38593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()' Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race: 'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL; To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires: [ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-39732", "url": "https://ubuntu.com/security/CVE-2025-39732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to ieee80211_iterate_stations_atomic(). Note in this case the iterator is required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does not follow it as it might sleep. Consequently below warning is seen: BUG: sleeping function called from invalid context at wmi.c:304 Call Trace: dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.cold Change to ieee80211_iterate_stations_mtx() to fix this issue. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30", "cve_priority": "medium", "cve_public_date": "2025-09-07 16:15:00 UTC" }, { "cve": "CVE-2025-38595", "url": "https://ubuntu.com/security/CVE-2025-38595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen: fix UAF in dmabuf_exp_from_pages() [dma_buf_fd() fixes; no preferences regarding the tree it goes through - up to xen folks] As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the objects destroyed on close - starting with gntdev_dmabuf itself. Fix that by doing reserving descriptor before anything else and do fd_install() only when everything had been set up.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38660", "url": "https://ubuntu.com/security/CVE-2025-38660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: [ceph] parse_longname(): strrchr() expects NUL-terminated string ... and parse_longname() is not guaranteed that. That's the reason why it uses kmemdup_nul() to build the argument for kstrtou64(); the problem is, kstrtou64() is not the only thing that need it. Just get a NUL-terminated copy of the entire thing and be done with that...", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38555", "url": "https://ubuntu.com/security/CVE-2025-38555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget : fix use-after-free in composite_dev_cleanup() 1. In func configfs_composite_bind() -> composite_os_desc_req_prepare(): if kmalloc fails, the pointer cdev->os_desc_req will be freed but not set to NULL. Then it will return a failure to the upper-level function. 2. in func configfs_composite_bind() -> composite_dev_cleanup(): it will checks whether cdev->os_desc_req is NULL. If it is not NULL, it will attempt to use it.This will lead to a use-after-free issue. BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0 Read of size 8 at addr 0000004827837a00 by task init/1 CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1 kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c gadget_dev_desc_UDC_store+0x264/0x27c", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2024-36331", "url": "https://ubuntu.com/security/CVE-2024-36331", "cve_description": "Improper initialization of CPU cache memory could allow a privileged attacker with hypervisor access to overwrite SEV-SNP guest memory resulting in loss of data integrity.", "cve_priority": "medium", "cve_public_date": "2025-09-06 18:15:00 UTC" }, { "cve": "CVE-2025-38560", "url": "https://ubuntu.com/security/CVE-2025-38560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sev: Evict cache lines during SNP memory validation An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation. CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed. Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38501", "url": "https://ubuntu.com/security/CVE-2025-38501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: limit repeated connections from clients with the same IP Repeated connections from clients with the same IP address may exhaust the max connections and prevent other normal client connections. This patch limit repeated connections from clients with the same IP.", "cve_priority": "medium", "cve_public_date": "2025-08-16 06:15:00 UTC" }, { "cve": "CVE-2025-38562", "url": "https://ubuntu.com/security/CVE-2025-38562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference error in generate_encryptionkey If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38566", "url": "https://ubuntu.com/security/CVE-2025-38566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix handling of server side tls alerts Scott Mayhew discovered a security exploit in NFS over TLS in tls_alert_recv() due to its assumption it can read data from the msg iterator's kvec.. kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer. This patch proposes to rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38568", "url": "https://ubuntu.com/security/CVE-2025-38568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing TCA_MQPRIO_TC_ENTRY_INDEX is validated using NLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the value TC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stack write in the fp[] array, which only has room for 16 elements (0–15). Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38571", "url": "https://ubuntu.com/security/CVE-2025-38571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix client side handling of tls alerts A security exploit was discovered in NFS over TLS in tls_alert_recv due to its assumption that there is valid data in the msghdr's iterator's kvec. Instead, this patch proposes the rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed control buffer and read in the control message such as a TLS alert. Scott found that a msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38622", "url": "https://ubuntu.com/security/CVE-2025-38622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop UFO packets in udp_rcv_segment() When sending a packet with virtio_net_hdr to tun device, if the gso_type in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr size, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 To trigger gso segment in udp_queue_rcv_skb(), we should also set option UDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcv hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try to pull udphdr, but the skb size has been segmented to gso size, which leads to this crash. Previous commit cf329aa42b66 (\"udp: cope with UDP GRO packet misdirection\") introduces segmentation in UDP receive path only for GRO, which was never intended to be used for UFO, so drop UFO packets in udp_rcv_segment().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38572", "url": "https://ubuntu.com/security/CVE-2025-38572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: reject malicious packets in ipv6_gso_segment() syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header. This 16bit field has a limited range. Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment() WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38574", "url": "https://ubuntu.com/security/CVE-2025-38574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pptp: ensure minimal skb length in pptp_xmit() Commit aabc6596ffb3 (\"net: ppp: Add bound checking for skb data on ppp_sync_txmung\") fixed ppp_sync_txmunge() We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot. BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-39730", "url": "https://ubuntu.com/security/CVE-2025-39730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() The function needs to check the minimal filehandle length before it can access the embedded filehandle.", "cve_priority": "medium", "cve_public_date": "2025-09-07 16:15:00 UTC" }, { "cve": "CVE-2025-38623", "url": "https://ubuntu.com/security/CVE-2025-38623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: pnv_php: Fix surprise plug detection and recovery The existing PowerNV hotplug code did not handle surprise plug events correctly, leading to a complete failure of the hotplug system after device removal and a required reboot to detect new devices. This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot. Issue the appropriate unfreeze and rescan commands on hotplug events, and don't oops on hotplug if pci_bus_to_OF_node() returns NULL. [bhelgaas: tidy comments]", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38576", "url": "https://ubuntu.com/security/CVE-2025-38576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Make EEH driver device hotplug safe Multiple race conditions existed between the PCIe hotplug driver and the EEH driver, leading to a variety of kernel oopses of the same general nature: A second class of oops is also seen when the underlying bus disappears during device recovery. Refactor the EEH module to be PCI rescan and remove safe. Also clean up a few minor formatting / readability issues.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38624", "url": "https://ubuntu.com/security/CVE-2025-38624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: pnv_php: Clean up allocated IRQs on unplug When the root of a nested PCIe bridge configuration is unplugged, the pnv_php driver leaked the allocated IRQ resources for the child bridges' hotplug event notifications, resulting in a panic. Fix this by walking all child buses and deallocating all its IRQ resources before calling pci_hp_remove_devices(). Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so that it is only destroyed in pnv_php_free_slot(), instead of pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will now be called by workers triggered by hot unplug interrupts, so the workqueue needs to stay allocated. The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec [bhelgaas: tidy comments]", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38625", "url": "https://ubuntu.com/security/CVE-2025-38625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pds: Fix missing detach_ioas op When CONFIG_IOMMUFD is enabled and a device is bound to the pds_vfio_pci driver, the following WARN_ON() trace is seen and probe fails: WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio] <...> pds_vfio_pci 0000:08:00.1: probe with driver pds_vfio_pci failed with error -22 This is because the driver's vfio_device_ops.detach_ioas isn't set. Fix this by using the generic vfio_iommufd_physical_detach_ioas function.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38626", "url": "https://ubuntu.com/security/CVE-2025-38626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ \"mode=lfs\" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-39731", "url": "https://ubuntu.com/security/CVE-2025-39731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: vm_unmap_ram() may be called from an invalid context When testing F2FS with xfstests using UFS backed virtual disks the kernel complains sometimes that f2fs_release_decomp_mem() calls vm_unmap_ram() from an invalid context. Example trace from f2fs/007 test: f2fs/007 5s ... [12:59:38][ 8.902525] run fstests f2fs/007 [ 11.468026] BUG: sleeping function called from invalid context at mm/vmalloc.c:2978 [ 11.471849] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 68, name: irq/22-ufshcd [ 11.475357] preempt_count: 1, expected: 0 [ 11.476970] RCU nest depth: 0, expected: 0 [ 11.478531] CPU: 0 UID: 0 PID: 68 Comm: irq/22-ufshcd Tainted: G W 6.16.0-rc5-xfstests-ufs-g40f92e79b0aa #9 PREEMPT(none) [ 11.478535] Tainted: [W]=WARN [ 11.478536] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 11.478537] Call Trace: [ 11.478543] [ 11.478545] dump_stack_lvl+0x4e/0x70 [ 11.478554] __might_resched.cold+0xaf/0xbe [ 11.478557] vm_unmap_ram+0x21/0xb0 [ 11.478560] f2fs_release_decomp_mem+0x59/0x80 [ 11.478563] f2fs_free_dic+0x18/0x1a0 [ 11.478565] f2fs_finish_read_bio+0xd7/0x290 [ 11.478570] blk_update_request+0xec/0x3b0 [ 11.478574] ? sbitmap_queue_clear+0x3b/0x60 [ 11.478576] scsi_end_request+0x27/0x1a0 [ 11.478582] scsi_io_completion+0x40/0x300 [ 11.478583] ufshcd_mcq_poll_cqe_lock+0xa3/0xe0 [ 11.478588] ufshcd_sl_intr+0x194/0x1f0 [ 11.478592] ufshcd_threaded_intr+0x68/0xb0 [ 11.478594] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478599] irq_thread_fn+0x20/0x60 [ 11.478602] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478603] irq_thread+0xb9/0x180 [ 11.478605] ? __pfx_irq_thread_dtor+0x10/0x10 [ 11.478607] ? __pfx_irq_thread+0x10/0x10 [ 11.478609] kthread+0x10a/0x230 [ 11.478614] ? __pfx_kthread+0x10/0x10 [ 11.478615] ret_from_fork+0x7e/0xd0 [ 11.478619] ? __pfx_kthread+0x10/0x10 [ 11.478621] ret_from_fork_asm+0x1a/0x30 [ 11.478623] This patch modifies in_task() check inside f2fs_read_end_io() to also check if interrupts are disabled. This ensures that pages are unmapped asynchronously in an interrupt handler.", "cve_priority": "medium", "cve_public_date": "2025-09-07 16:15:00 UTC" }, { "cve": "CVE-2025-38652", "url": "https://ubuntu.com/security/CVE-2025-38652", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-boundary access in devs.path - touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - truncate -s $((1024*1024*1024)) \\ /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - touch /mnt/f2fs/file - truncate -s $((1024*1024*1024)) /mnt/f2fs/file - mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \\ -c /mnt/f2fs/file - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \\ /mnt/f2fs/loop [16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\\xff\\x01, 511, 0 - 3ffff [16937.192268] F2FS-fs (loop0): Failed to find devices If device path length equals to MAX_PATH_LEN, sbi->devs.path[] may not end up w/ null character due to path array is fully filled, So accidently, fields locate after path[] may be treated as part of device path, result in parsing wrong device path. struct f2fs_dev_info { ... \tchar path[MAX_PATH_LEN]; ... }; Let's add one byte space for sbi->devs.path[] to store null character of device path string.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38577", "url": "https://ubuntu.com/security/CVE-2025-38577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid panic in f2fs_evict_inode As syzbot [1] reported as below: R10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 ---[ end trace 0000000000000000 ]--- ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff88812d962278 by task syz-executor/564 CPU: 1 PID: 564 Comm: syz-executor Tainted: G W 6.1.129-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack+0x21/0x24 lib/dump_stack.c:88 dump_stack_lvl+0xee/0x158 lib/dump_stack.c:106 print_address_description+0x71/0x210 mm/kasan/report.c:316 print_report+0x4a/0x60 mm/kasan/report.c:427 kasan_report+0x122/0x150 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531 f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585 f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703 f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4a0/0xab0 fs/fs-writeback.c:1677 writeback_single_inode+0x221/0x8b0 fs/fs-writeback.c:1733 sync_inode_metadata+0xb6/0x110 fs/fs-writeback.c:2789 f2fs_sync_inode_meta+0x16d/0x2a0 fs/f2fs/checkpoint.c:1159 block_operations fs/f2fs/checkpoint.c:1269 [inline] f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658 kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668 deactivate_locked_super+0x98/0x100 fs/super.c:332 deactivate_super+0xaf/0xe0 fs/super.c:363 cleanup_mnt+0x45f/0x4e0 fs/namespace.c:1186 __cleanup_mnt+0x19/0x20 fs/namespace.c:1193 task_work_run+0x1c6/0x230 kernel/task_work.c:203 exit_task_work include/linux/task_work.h:39 [inline] do_exit+0x9fb/0x2410 kernel/exit.c:871 do_group_exit+0x210/0x2d0 kernel/exit.c:1021 __do_sys_exit_group kernel/exit.c:1032 [inline] __se_sys_exit_group kernel/exit.c:1030 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030 x64_sys_call+0x7b4/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 RIP: 0033:0x7f28b1b8e169 Code: Unable to access opcode bytes at 0x7f28b1b8e13f. RSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 Allocated by task 569: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook+0x4f/0x2c0 mm/slab.h:737 slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3245 [inline] f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419 alloc_inode fs/inode.c:261 [inline] iget_locked+0x186/0x880 fs/inode.c:1373 f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483 f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487 __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690 lookup_slow+0x57/0x70 fs/namei.c:1707 walk_component+0x2e6/0x410 fs/namei ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38578", "url": "https://ubuntu.com/security/CVE-2025-38578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid UAF in f2fs_sync_inode_meta() syzbot reported an UAF issue as below: [1] [2] [1] https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000 ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff888100567dc8 by task kworker/u4:0/8 CPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G W 6.1.129-syzkaller-00017-g642656a36791 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x151/0x1b7 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x158/0x4e0 mm/kasan/report.c:427 kasan_report+0x13c/0x170 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553 f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588 f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706 f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677 writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903 __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974 wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081 wb_check_background_flush fs/fs-writeback.c:2151 [inline] wb_do_writeback fs/fs-writeback.c:2239 [inline] wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266 process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299 worker_thread+0xa60/0x1260 kernel/workqueue.c:2446 kthread+0x26d/0x300 kernel/kthread.c:386 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Allocated by task 298: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333 kasan_slab_alloc include/linux/kasan.h:202 [inline] slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768 slab_alloc_node mm/slub.c:3421 [inline] slab_alloc mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline] kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454 alloc_inode_sb include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline] iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486 f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484 __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689 lookup_slow+0x5a/0x80 fs/namei.c:1706 walk_component+0x2e7/0x410 fs/namei.c:1997 lookup_last fs/namei.c:2454 [inline] path_lookupat+0x16d/0x450 fs/namei.c:2478 filename_lookup+0x251/0x600 fs/namei.c:2507 vfs_statx+0x107/0x4b0 fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat include/linux/fs.h:3434 [inline] __do_sys_newlstat fs/stat.c:423 [inline] __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417 x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by task 0: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516 ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241 __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249 kasan_slab_free include/linux/kasan.h:178 [inline] slab_free_hook mm/slub.c:1745 [inline] slab_free_freelist_hook mm/slub.c:1771 [inline] slab_free mm/slub.c:3686 [inline] kmem_cache_free+0x ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38579", "url": "https://ubuntu.com/security/CVE-2025-38579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix KMSAN uninit-value in extent_info usage KMSAN reported a use of uninitialized value in `__is_extent_mergeable()` and `__is_back_mergeable()` via the read extent tree path. The root cause is that `get_read_extent_info()` only initializes three fields (`fofs`, `blk`, `len`) of `struct extent_info`, leaving the remaining fields uninitialized. This leads to undefined behavior when those fields are accessed later, especially during extent merging. Fix it by zero-initializing the `extent_info` struct before population.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38630", "url": "https://ubuntu.com/security/CVE-2025-38630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref fb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannot allocate a struct fb_modelist. If that happens, the modelist stays empty but the driver continues to register. Add a check for its return value to prevent poteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 (\"fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var\").", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38632", "url": "https://ubuntu.com/security/CVE-2025-38632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinmux: fix race causing mux_owner NULL with active mux_usecount commit 5a3e85c3c397 (\"pinmux: Use sequential access to access desc->pinmux data\") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer. The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux) This sequence leads to a state where the pin appears to be in use (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can cause NULL pointer on next pin_request on the same pin. Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38653", "url": "https://ubuntu.com/security/CVE-2025-38653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. It's a gap in proc_reg_open() after commit 654b33ada4ab(\"proc: fix UAF in proc_get_inode()\"). Followed by AI Viro's suggestion, fix it in same manner.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38581", "url": "https://ubuntu.com/security/CVE-2025-38581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix crash when rebind ccp device for ccp.ko When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38634", "url": "https://ubuntu.com/security/CVE-2025-38634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-charger: Fix null check for power_supply_get_by_name In the cpcap_usb_detect() function, the power_supply_get_by_name() function may return `NULL` instead of an error pointer. To prevent potential null pointer dereferences, Added a null check.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38583", "url": "https://ubuntu.com/security/CVE-2025-38583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: xilinx: vcu: unregister pll_post only if registered correctly If registration of pll_post is failed, it will be set to NULL or ERR, unregistering same will fail with following call trace: Unable to handle kernel NULL pointer dereference at virtual address 008 pc : clk_hw_unregister+0xc/0x20 lr : clk_hw_unregister_fixed_factor+0x18/0x30 sp : ffff800011923850 ... Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu]", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38635", "url": "https://ubuntu.com/security/CVE-2025-38635", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: davinci: Add NULL check in davinci_lpsc_clk_register() devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38587", "url": "https://ubuntu.com/security/CVE-2025-38587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible infinite loop in fib6_info_uses_dev() fib6_info_uses_dev() seems to rely on RCU without an explicit protection. Like the prior fix in rt6_nlmsg_size(), we need to make sure fib6_del_route() or fib6_add_rt2node() have not removed the anchor from the list, or we risk an infinite loop.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38588", "url": "https://ubuntu.com/security/CVE-2025-38588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent infinite loop in rt6_nlmsg_size() While testing prior patch, I was able to trigger an infinite loop in rt6_nlmsg_size() in the following place: list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, \t\t\tfib6_siblings) { \trt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); } This is because fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can confuse rcu readers, because they might no longer see the head of the list. Restart the loop if f6i->fib6_nsiblings is zero.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38590", "url": "https://ubuntu.com/security/CVE-2025-38590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Remove skb secpath if xfrm state is not found Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup. Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0. Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer. This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 ", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38639", "url": "https://ubuntu.com/security/CVE-2025-38639", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_nfacct: don't assume acct name is null-terminated BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721 Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851 [..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523 nfnl_acct_find_get() handles non-null input, but the error printk relied on its presence.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38640", "url": "https://ubuntu.com/security/CVE-2025-38640", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disable migration in nf_hook_run_bpf(). syzbot reported that the netfilter bpf prog can be called without migration disabled in xmit path. Then the assertion in __bpf_prog_run() fails, triggering the splat below. [0] Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf(). [0]: BUG: assuming non migratable context at ./include/linux/filter.h:703 in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session 3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241 CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe7d365d407 Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP:", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38644", "url": "https://ubuntu.com/security/CVE-2025-38644", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reject TDLS operations when station is not associated syzbot triggered a WARN in ieee80211_tdls_oper() by sending NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT, before association completed and without prior TDLS setup. This left internal state like sdata->u.mgd.tdls_peer uninitialized, leading to a WARN_ON() in code paths that assumed it was valid. Reject the operation early if not in station mode or not associated.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38553", "url": "https://ubuntu.com/security/CVE-2025-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Restrict conditions for adding duplicating netems to qdisc tree netem_enqueue's duplication prevention logic breaks when a netem resides in a qdisc tree with other netems - this can lead to a soft lockup and OOM loop in netem_dequeue, as seen in [1]. Ensure that a duplicating netem cannot exist in a tree with other netems. Previous approaches suggested in discussions in chronological order: 1) Track duplication status or ttl in the sk_buff struct. Considered too specific a use case to extend such a struct, though this would be a resilient fix and address other previous and potential future DOS bugs like the one described in loopy fun [2]. 2) Restrict netem_enqueue recursion depth like in act_mirred with a per cpu variable. However, netem_dequeue can call enqueue on its child, and the depth restriction could be bypassed if the child is a netem. 3) Use the same approach as in 2, but add metadata in netem_skb_cb to handle the netem_dequeue case and track a packet's involvement in duplication. This is an overly complex approach, and Jamal notes that the skb cb can be overwritten to circumvent this safeguard. 4) Prevent the addition of a netem to a qdisc tree if its ancestral path contains a netem. However, filters and actions can cause a packet to change paths when re-enqueued to the root from netem duplication, leading us to the current solution: prevent a duplicating netem from inhabiting the same tree as other netems. [1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/ [2] https://lwn.net/Articles/719297/", "cve_priority": "medium", "cve_public_date": "2025-08-19 06:15:00 UTC" }, { "cve": "CVE-2025-38645", "url": "https://ubuntu.com/security/CVE-2025-38645", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Check device memory pointer before usage Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5_init_once() fails.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38601", "url": "https://ubuntu.com/security/CVE-2025-38601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: clear initialized flag for deinit-ed srng lists In a number of cases we see kernel panics on resume due to ath11k kernel page fault, which happens under the following circumstances: 1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..] 2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag. 3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170 Clear per-list ->initialized flag in ath11k_hal_srng_deinit().", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38602", "url": "https://ubuntu.com/security/CVE-2025-38602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iwlwifi: Add missing check for alloc_ordered_workqueue Add check for the return value of alloc_ordered_workqueue since it may return NULL pointer.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38604", "url": "https://ubuntu.com/security/CVE-2025-38604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Kill URBs before clearing tx status queue In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing b_tx_status.queue. This change prevents callbacks from using already freed skb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Tested on RTL8187BvE device. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38646", "url": "https://ubuntu.com/security/CVE-2025-38646", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band With a quite rare chance, RX report might be problematic to make SW think a packet is received on 6 GHz band even if the chip does not support 6 GHz band actually. Since SW won't initialize stuffs for unsupported bands, NULL dereference will happen then in the sequence, rtw89_vif_rx_stats_iter() -> rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it. The following is a crash log for this case. BUG: kernel NULL pointer dereference, address: 0000000000000032 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G U 6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4) Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024 RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core] Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 <41> 33 45 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85 RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246 RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011 RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6 RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000 R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4 R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)] __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)] rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)] rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)]", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38608", "url": "https://ubuntu.com/security/CVE-2025-38608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls When sending plaintext data, we initially calculated the corresponding ciphertext length. However, if we later reduced the plaintext data length via socket policy, we failed to recalculate the ciphertext length. This results in transmitting buffers containing uninitialized data during ciphertext transmission. This causes uninitialized bytes to be appended after a complete \"Application Data\" packet, leading to errors on the receiving end when parsing TLS record.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38609", "url": "https://ubuntu.com/security/CVE-2025-38609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Check governor before using governor->name Commit 96ffcdf239de (\"PM / devfreq: Remove redundant governor_name from struct devfreq\") removes governor_name and uses governor->name to replace it. But devfreq->governor may be NULL and directly using devfreq->governor->name may cause null pointer exception. Move the check of governor to before using governor->name.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38610", "url": "https://ubuntu.com/security/CVE-2025-38610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() The get_pd_power_uw() function can crash with a NULL pointer dereference when em_cpu_get() returns NULL. This occurs when a CPU becomes impossible during runtime, causing get_cpu_device() to return NULL, which propagates through em_cpu_get() and leads to a crash when em_span_cpus() dereferences the NULL pointer. Add a NULL check after em_cpu_get() and return 0 if unavailable, matching the existing fallback behavior in __dtpm_cpu_setup(). [ rjw: Drop an excess empty code line ]", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38612", "url": "https://ubuntu.com/security/CVE-2025-38612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() In the error paths after fb_info structure is successfully allocated, the memory allocated in fb_deferred_io_init() for info->pagerefs is not freed. Fix that by adding the cleanup function on the error path.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38648", "url": "https://ubuntu.com/security/CVE-2025-38648", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: stm32: Check for cfg availability in stm32_spi_probe The stm32_spi_probe function now includes a check to ensure that the pointer returned by of_device_get_match_data is not NULL before accessing its members. This resolves a warning where a potential NULL pointer dereference could occur when accessing cfg->has_device_mode. Before accessing the 'has_device_mode' member, we verify that 'cfg' is not NULL. If 'cfg' is NULL, an error message is logged. This change ensures that the driver does not attempt to access configuration data if it is not available, thus preventing a potential system crash due to a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38659", "url": "https://ubuntu.com/security/CVE-2025-38659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: No more self recovery When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-39734", "url": "https://ubuntu.com/security/CVE-2025-39734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"fs/ntfs3: Replace inode_trylock with inode_lock\" This reverts commit 69505fe98f198ee813898cbcaf6770949636430b. Initially, conditional lock acquisition was removed to fix an xfstest bug that was observed during internal testing. The deadlock reported by syzbot is resolved by reintroducing conditional acquisition. The xfstest bug no longer occurs on kernel version 6.16-rc1 during internal testing. I assume that changes in other modules may have contributed to this.", "cve_priority": "medium", "cve_public_date": "2025-09-07 16:15:00 UTC" }, { "cve": "CVE-2025-38650", "url": "https://ubuntu.com/security/CVE-2025-38650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: remove mutex_lock check in hfsplus_free_extents Syzbot reported an issue in hfsplus filesystem: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 \thfsplus_free_extents+0x700/0xad0 Call Trace: hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606 hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56 cont_expand_zero fs/buffer.c:2383 [inline] cont_write_begin+0x2cf/0x860 fs/buffer.c:2446 hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52 generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347 hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263 notify_change+0xe38/0x10f0 fs/attr.c:420 do_truncate+0x1fb/0x2e0 fs/open.c:65 do_sys_ftruncate+0x2eb/0x380 fs/open.c:193 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd To avoid deadlock, Commit 31651c607151 (\"hfsplus: avoid deadlock on file truncation\") unlock extree before hfsplus_free_extents(), and add check wheather extree is locked in hfsplus_free_extents(). However, when operations such as hfsplus_file_release, hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed concurrently in different files, it is very likely to trigger the WARN_ON, which will lead syzbot and xfstest to consider it as an abnormality. The comment above this warning also describes one of the easy triggering situations, which can easily trigger and cause xfstest&syzbot to report errors. [task A]\t\t\t[task B] ->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock \t\t\t\t->hfsplus_write_begin \t\t\t\t ->hfsplus_get_block \t\t\t\t ->hfsplus_file_extend \t\t\t\t ->hfsplus_ext_read_extent \t\t\t\t ->hfs_find_init \t\t\t\t\t ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!! Several threads could try to lock the shared extents tree. And warning can be triggered in one thread when another thread has locked the tree. This is the wrong behavior of the code and we need to remove the warning.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38615", "url": "https://ubuntu.com/security/CVE-2025-38615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's \"icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier\". In some it's outright \"we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles\".", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38351", "url": "https://ubuntu.com/security/CVE-2025-38351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated. However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error(): invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm] Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms \"real\" Hyper-V interprets the specification in the same way. Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out \"bad\" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.", "cve_priority": "medium", "cve_public_date": "2025-07-19 12:15:00 UTC" }, { "cve": "CVE-2025-38675", "url": "https://ubuntu.com/security/CVE-2025-38675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: state: initialize state_ptrs earlier in xfrm_state_find In case of preemption, xfrm_state_look_at will find a different pcpu_id and look up states for that other CPU. If we matched a state for CPU2 in the state_cache while the lookup started on CPU1, we will jump to \"found\", but the \"best\" state that we got will be ignored and we will enter the \"acquire\" block. This block uses state_ptrs, which isn't initialized at this point. Let's initialize state_ptrs just after taking rcu_read_lock. This will also prevent a possible misuse in the future, if someone adjusts this function.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38322", "url": "https://ubuntu.com/security/CVE-2025-38322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix crash in icl_update_topdown_event() The perf_fuzzer found a hard-lockup crash on a RaptorLake machine: Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision 9660/0VJ762 RIP: 0010:native_read_pmc+0x7/0x40 Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Call Trace: icl_update_topdown_event+0x165/0x190 ? ktime_get+0x38/0xd0 intel_pmu_read_event+0xf9/0x210 __perf_event_read+0xf9/0x210 CPUs 16-23 are E-core CPUs that don't support the perf metrics feature. The icl_update_topdown_event() should not be invoked on these CPUs. It's a regression of commit: f9bdf1f95339 (\"perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read\") The bug introduced by that commit is that the is_topdown_event() function is mistakenly used to replace the is_topdown_count() call to check if the topdown functions for the perf metrics feature should be invoked. Fix it.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-37777", "url": "https://ubuntu.com/security/CVE-2025-37777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __smb2_lease_break_noti() Move tcp_transport free to ksmbd_conn_free. If ksmbd connection is referenced when ksmbd server thread terminates, It will not be freed, but conn->tcp_transport is freed. __smb2_lease_break_noti can be performed asynchronously when the connection is disconnected. __smb2_lease_break_noti calls ksmbd_conn_write, which can cause use-after-free when conn->ksmbd_transport is already freed.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37925", "url": "https://ubuntu.com/security/CVE-2025-37925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: reject on-disk inodes of an unsupported type Syzbot has reported the following BUG: kernel BUG at fs/inode.c:668! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clear_inode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This happens when 'clear_inode()' makes an attempt to finalize an underlying JFS inode of unknown type. According to JFS layout description from https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to 15 are reserved for future extensions and should not be encountered on a valid filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-38663", "url": "https://ubuntu.com/security/CVE-2025-38663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid file types when reading inodes To prevent inodes with invalid file types from tripping through the vfs and causing malfunctions or assertion failures, add a missing sanity check when reading an inode from a block device. If the file type is not valid, treat it as a filesystem error.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38664", "url": "https://ubuntu.com/security/CVE-2025-38664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix a null pointer dereference in ice_copy_and_init_pkg() Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38670", "url": "https://ubuntu.com/security/CVE-2025-38670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks. In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SP_EL0), clobbering it. In `call_on_irq_stack()`, it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls `call_on_irq_stack()` and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use ! This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK or FPAC if enabled. This is possible on a default config, but unlikely. However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very* frequently depending on the system configuration and workload, leading to unpredictable kernel panics. Completely mask DAIF in `cpu_switch_to()` and restore it when returning. Do the same in `call_on_irq_stack()`, but restore and mask around the branch. Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency of behaviour between all configurations. Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38671", "url": "https://ubuntu.com/security/CVE-2025-38671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qup: jump out of the loop in case of timeout Original logic only sets the return value but doesn't jump out of the loop if the bus is kept active by a client. This is not expected. A malicious or buggy i2c client can hang the kernel in this case and should be avoided. This is observed during a long time test with a PCA953x GPIO extender. Fix it by changing the logic to not only sets the return value, but also jumps out of the loop and return to the caller with -ETIMEDOUT.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-39726", "url": "https://ubuntu.com/security/CVE-2025-39726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-38665", "url": "https://ubuntu.com/security/CVE-2025-38665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode Andrei Lalaev reported a NULL pointer deref when a CAN device is restarted from Bus Off and the driver does not implement the struct can_priv::do_set_mode callback. There are 2 code path that call struct can_priv::do_set_mode: - directly by a manual restart from the user space, via can_changelink() - delayed automatic restart after bus off (deactivated by default) To prevent the NULL pointer deference, refuse a manual restart or configure the automatic restart delay in can_changelink() and report the error via extack to user space. As an additional safety measure let can_restart() return an error if can_priv::do_set_mode is not set instead of dereferencing it unchecked.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38668", "url": "https://ubuntu.com/security/CVE-2025-38668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix NULL dereference on unbind due to stale coupling data Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind. This can happen during runtime PM or other regulator operations that rely on coupling metadata. For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state. Ensure n_coupled is set to 0 to prevent access to invalid pointers.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38335", "url": "https://ubuntu.com/security/CVE-2025-38335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context, but the input_event() takes a spin_lock, which isn't allowed there as it is converted to a rt_spin_lock(). [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context. Relax the hrtimer not to use the hard context.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-22115", "url": "https://ubuntu.com/security/CVE-2025-22115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix block group refcount race in btrfs_create_pending_block_groups() Block group creation is done in two phases, which results in a slightly unintuitive property: a block group can be allocated/deallocated from after btrfs_make_block_group() adds it to the space_info with btrfs_add_bg_to_space_info(), but before creation is completely completed in btrfs_create_pending_block_groups(). As a result, it is possible for a block group to go unused and have 'btrfs_mark_bg_unused' called on it concurrently with 'btrfs_create_pending_block_groups'. This causes a number of issues, which were fixed with the block group flag 'BLOCK_GROUP_FLAG_NEW'. However, this fix is not quite complete. Since it does not use the unused_bg_lock, it is possible for the following race to occur: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail And we get into the exact same broken ref count and invalid new_bgs state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to prevent. The broken refcount aspect will result in a warning like: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] [1272.961238] ---[ end trace 0000000000000000 ]--- Though we have seen them in the async discard workfn as well. It is most likely to happen after a relocation finishes which cancels discard, tears down the block group, etc. Fix this fully by taking the lock arou ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38549", "url": "https://ubuntu.com/security/CVE-2025-38549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths When processing mount options, efivarfs allocates efivarfs_fs_info (sfi) early in fs_context initialization. However, sfi is associated with the superblock and typically freed when the superblock is destroyed. If the fs_context is released (final put) before fill_super is called—such as on error paths or during reconfiguration—the sfi structure would leak, as ownership never transfers to the superblock. Implement the .free callback in efivarfs_context_ops to ensure any allocated sfi is properly freed if the fs_context is torn down before fill_super, preventing this memory leak.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38551", "url": "https://ubuntu.com/security/CVE-2025-38551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix recursived rtnl_lock() during probe() The deadlock appears in a stack trace like: virtnet_probe() rtnl_lock() virtio_config_changed_work() netdev_notify_peers() rtnl_lock() It happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the virtio-net driver is still probing. The config_work in probe() will get scheduled until virtnet_open() enables the config change notification via virtio_config_driver_enable().", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38531", "url": "https://ubuntu.com/security/CVE-2025-38531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: common: st_sensors: Fix use of uninitialize device structs Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device. This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well. The issue is reported and traced here: [1]", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38552", "url": "https://ubuntu.com/security/CVE-2025-38552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: plug races between subflow fail and subflow creation We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger. The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock. The socket fallback makes such flag true, and also receiving or sending an MP_FAIL option. The field 'allow_infinite_fallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38491", "url": "https://ubuntu.com/security/CVE-2025-38491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: make fallback action and fallback decision atomic Syzkaller reported the following splat: WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline] RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432 tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975 tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166 tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline] ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644 handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90 kernel/softirq.c:480 __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33 [inline] inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524 mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcp_check_listen_stop net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435 inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70 fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xd4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38469", "url": "https://ubuntu.com/security/CVE-2025-38469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll hypercalls kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host for more than one event channel potr (nr_ports > 1). After the kmalloc_array(), the error paths need to go through the \"out\" label, but the call to kvm_read_guest_virt() does not. [Adjusted commit message. - Paolo]", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38499", "url": "https://ubuntu.com/security/CVE-2025-38499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. \"Wouldn't be able to undo\" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above.", "cve_priority": "medium", "cve_public_date": "2025-08-11 16:15:00 UTC" }, { "cve": "CVE-2025-38524", "url": "https://ubuntu.com/security/CVE-2025-38524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recv-recv race of completed call If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again. In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be \"released\", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly: \tkernel BUG at net/rxrpc/recvmsg.c:474! Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38468", "url": "https://ubuntu.com/security/CVE-2025-38468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree htb_lookup_leaf has a BUG_ON that can trigger with the following: tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 htb rate 64bit tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2:1 handle 3: blackhole ping -I lo -c1 -W0.001 127.0.0.1 The root cause is the following: 1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc 2. netem_dequeue calls enqueue on the child qdisc 3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase 5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ON The function graph for this scenario is shown here: 0) | htb_enqueue() { 0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() { 0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() { 0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() { 0) | qdisc_lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() { 0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() { 0) | BUG_ON(); ------------------------------------------ The full original bug report can be seen here [1]. We can fix this just by returning NULL instead of the BUG_ON, as htb_dequeue_tree returns NULL when htb_lookup_leaf returns NULL. [1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38470", "url": "https://ubuntu.com/security/CVE-2025-38470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime Assuming the \"rx-vlan-filter\" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme. The first problem is a memory leak that can happen if the \"rx-vlan-filter\" feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1 When the device is put administratively down the \"rx-vlan-filter\" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1]. Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the \"rx-vlan-filter\" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime: $ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0 Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the \"rx-vlan-filter\" feature. [1] unreferenced object 0xffff8880068e3100 (size 256): comm \"ip\", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 [2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: stm.full_len\").", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38472", "url": "https://ubuntu.com/security/CVE-2025-38472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: fix crash due to removal of uninitialised entry A crash in conntrack was reported while trying to unlink the conntrack entry from the hash bucket list: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..] The nf_conn struct is marked as allocated from slab but appears to be in a partially initialised state: ct hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected. Everything else looks like normal udp conntrack entry. If we ignore ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value. If it were not for the presence of IPS_CONFIRMED, __nf_conntrack_find_get() would have skipped the entry. Theory is that we did hit following race: cpu x \t\t\tcpu y\t\t\tcpu z found entry E\t\tfound entry E E is expired\t\t nf_ct_delete() return E to rcu slab \t\t\t\t\tinit_conntrack \t\t\t\t\tE is re-inited, \t\t\t\t\tct->status set to 0 \t\t\t\t\treply tuplehash hnnode.pprev \t\t\t\t\tstores hash value. cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y was preempted before checking for expiry and/or confirm bit. \t\t\t\t\t->refcnt set to 1 \t\t\t\t\tE now owned by skb \t\t\t\t\t->timeout set to 30000 If cpu y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit. \t\t\t\t\tnf_conntrack_confirm gets called \t\t\t\t\tsets: ct->status |= CONFIRMED \t\t\t\t\tThis is wrong: E is not yet added \t\t\t\t\tto hashtable. cpu y resumes, it observes E as expired but CONFIRMED: \t\t\t \t\t\tnf_ct_expired() \t\t\t -> yes (ct->timeout is 30s) \t\t\tconfirmed bit set. cpu y will try to delete E from the hashtable: \t\t\tnf_ct_delete() -> set DYING bit \t\t\t__nf_ct_delete_from_lists Even this scenario doesn't guarantee a crash: cpu z still holds the table bucket lock(s) so y blocks: \t\t\twait for spinlock held by z \t\t\t\t\tCONFIRMED is set but there is no \t\t\t\t\tguarantee ct will be added to hash: \t\t\t\t\t\"chaintoolong\" or \"clash resolution\" \t\t\t\t\tlogic both skip the insert step. \t\t\t\t\treply hnnode.pprev still stores the \t\t\t\t\thash value. \t\t\t\t\tunlocks spinlock \t\t\t\t\treturn NF_DROP \t\t\t In case CPU z does insert the entry into the hashtable, cpu y will unlink E again right away but no crash occurs. Without 'cpu y' race, 'garbage' hlist is of no consequence: ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy. To resolve this, move the IPS_CONFIRMED assignment after the table insertion but before the unlock. Pablo points out that the confirm-bit-store could be reordered to happen before hlist add resp. the timeout fixup, so switch to set_bit and before_atomic memory barrier to prevent this. It doesn't matter if other CPUs can observe a newly inserted entry right before the CONFIRMED bit was set: Such event cannot be distinguished from above \"E is the old incarnation\" case: the entry will be skipped. Also change nf_ct_should_gc() to first check the confirmed bit. The gc sequence is: 1. Check if entry has expired, if not skip to next entry 2. Obtain a reference to the expired entry. 3. Call nf_ct_should_gc() to double-check step 1. nf_ct_should_gc() is thus called only for entries that already failed an expiry check. After this patch, once the confirmed bit check pas ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38550", "url": "https://ubuntu.com/security/CVE-2025-38550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Delay put pmc->idev in mld_del_delrec() pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec() does, the reference should be put after ip6_mc_clear_src() return.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38473", "url": "https://ubuntu.com/security/CVE-2025-38473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0] l2cap_sock_resume_cb() has a similar problem that was fixed by commit 1bff51ea59a9 (\"Bluetooth: fix use-after-free error in lock_sock_nested()\"). Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed under l2cap_sock_resume_cb(), we can avoid the issue simply by checking if chan->data is NULL. Let's not access to the killed socket in l2cap_sock_resume_cb(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: hci0 hci_rx_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38474", "url": "https://ubuntu.com/security/CVE-2025-38474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: net: sierra: check for no status endpoint The driver checks for having three endpoints and having bulk in and out endpoints, but not that the third endpoint is interrupt input. Rectify the omission.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38526", "url": "https://ubuntu.com/security/CVE-2025-38526", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: add NULL check in eswitch lag check The function ice_lag_is_switchdev_running() is being called from outside of the LAG event handler code. This results in the lag->upper_netdev being NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a check before it is dereferenced.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38548", "url": "https://ubuntu.com/security/CVE-2025-38548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Validate the size of the received input buffer Add buffer_recv_size to store the size of the received bytes. Validate buffer_recv_size in send_usb_cmd().", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38537", "url": "https://ubuntu.com/security/CVE-2025-38537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Don't register LEDs for genphy If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an \"leds\" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38527", "url": "https://ubuntu.com/security/CVE-2025-38527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in cifs_oplock_break A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free. Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38476", "url": "https://ubuntu.com/security/CVE-2025-38476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpl: Fix use-after-free in rpl_do_srh_inline(). Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers the splat below [0]. rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after skb_cow_head(), which is illegal as the header could be freed then. Let's fix it by making oldhdr to a local struct instead of a pointer. [0]: [root@fedora net]# ./lwt_dst_cache_ref_loop.sh ... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543 CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2)) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 Allocated by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1)) ip6_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38528", "url": "https://ubuntu.com/security/CVE-2025-38528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject %p% format string in bprintf-like helpers static const char fmt[] = \"%p%\"; bpf_trace_printk(fmt, sizeof(fmt)); The above BPF program isn't rejected and causes a kernel warning at runtime: Please remove unsupported %\\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0 This happens because bpf_bprintf_prepare skips over the second %, detected as punctuation, while processing %p. This patch fixes it by not skipping over punctuation. %\\x00 is then processed in the next iteration and rejected.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38478", "url": "https://ubuntu.com/security/CVE-2025-38478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Fix initialization of data for instructions that write to subdevice Some Comedi subdevice instruction handlers are known to access instruction data elements beyond the first `insn->n` elements in some cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions allocate at least `MIN_SAMPLES` (16) data elements to deal with this, but they do not initialize all of that. For Comedi instruction codes that write to the subdevice, the first `insn->n` data elements are copied from user-space, but the remaining elements are left uninitialized. That could be a problem if the subdevice instruction handler reads the uninitialized data. Ensure that the first `MIN_SAMPLES` elements are initialized before calling these instruction handlers, filling the uncopied elements with 0. For `do_insnlist_ioctl()`, the same data buffer elements are used for handling a list of instructions, so ensure the first `MIN_SAMPLES` elements are initialized for each instruction that writes to the subdevice.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38480", "url": "https://ubuntu.com/security/CVE-2025-38480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Fix use of uninitialized data in insn_rw_emulate_bits() For Comedi `INSN_READ` and `INSN_WRITE` instructions on \"digital\" subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and `COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have `insn_read` and `insn_write` handler functions, but to have an `insn_bits` handler function for handling Comedi `INSN_BITS` instructions. In that case, the subdevice's `insn_read` and/or `insn_write` function handler pointers are set to point to the `insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`. For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the supplied `data[0]` value is a valid copy from user memory. It will at least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in \"comedi_fops.c\" ensure at lease `MIN_SAMPLES` (16) elements are allocated. However, if `insn->n` is 0 (which is allowable for `INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain uninitialized data, and certainly contains invalid data, possibly from a different instruction in the array of instructions handled by `do_insnlist_ioctl()`. This will result in an incorrect value being written to the digital output channel (or to the digital input/output channel if configured as an output), and may be reflected in the internal saved state of the channel. Fix it by returning 0 early if `insn->n` is 0, before reaching the code that accesses `data[0]`. Previously, the function always returned 1 on success, but it is supposed to be the number of data samples actually read or written up to `insn->n`, which is 0 in this case.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38481", "url": "https://ubuntu.com/security/CVE-2025-38481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to hold the array of `struct comedi_insn`, getting the length from the `n_insns` member of the `struct comedi_insnlist` supplied by the user. The allocation will fail with a WARNING and a stack dump if it is too large. Avoid that by failing with an `-EINVAL` error if the supplied `n_insns` value is unreasonable. Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Set this to the same value as `MAX_SAMPLES` (65536), which is the maximum allowed sum of the values of the member `n` in the array of `struct comedi_insn`, and sensible comedi instructions will have an `n` of at least 1.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38482", "url": "https://ubuntu.com/security/CVE-2025-38482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: das6402: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: \t/* IRQs 2,3,5,6,7, 10,11,15 are valid for \"enhanced\" mode */ \tif ((1 << it->options[1]) & 0x8cec) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38483", "url": "https://ubuntu.com/security/CVE-2025-38483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: das16m1: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: \t/* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ \tif ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38529", "url": "https://ubuntu.com/security/CVE-2025-38529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: aio_iiro_16: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: \tif ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38530", "url": "https://ubuntu.com/security/CVE-2025-38530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: pcl812: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: \tif ((1 << it->options[1]) & board->irq_bits) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38485", "url": "https://ubuntu.com/security/CVE-2025-38485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with iio_for_each_active_channel()) without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode in the middle of the interrupt that flushes the fifo. Fix this by calling synchronize_irq() to ensure that no interrupt is currently running when disabling buffer mode. Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [...] _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290 fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178 fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c irq_thread_fn from irq_thread+0x110/0x1f4 irq_thread from kthread+0xe0/0xfc kthread from ret_from_fork+0x14/0x2c", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38487", "url": "https://ubuntu.com/security/CVE-2025-38487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled Mitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ...", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2024-50047", "url": "https://ubuntu.com/security/CVE-2024-50047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Call Trace: [ 194.200191] [ 194.200327] dump_stack_lvl+0x4e/0x70 [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110 [ 194.200809] print_report+0x174/0x505 [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 194.201352] ? srso_return_thunk+0x5/0x5f [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0 [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()). Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it's always going to be a synchronous operation.", "cve_priority": "high", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2025-38488", "url": "https://ubuntu.com/security/CVE-2025-38488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in crypt_message when using async crypto The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...); Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory. This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences. The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected. Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for async completion notification - crypto_wait_req() to wait for operation completion This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38489", "url": "https://ubuntu.com/security/CVE-2025-38489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again Commit 7ded842b356d (\"s390/bpf: Fix bpf_plt pointer arithmetic\") has accidentally removed the critical piece of commit c730fce7c70c (\"s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL\"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear. Restore the fix and add a comment.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38532", "url": "https://ubuntu.com/security/CVE-2025-38532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: properly reset Rx ring descriptor When device reset is triggered by feature changes such as toggling Rx VLAN offload, wx->do_reset() is called to reinitialize Rx rings. The hardware descriptor ring may retain stale values from previous sessions. And only set the length to 0 in rx_desc[0] would result in building malformed SKBs. Fix it to ensure a clean slate after device reset. [ 549.186435] [ C16] ------------[ cut here ]------------ [ 549.186457] [ C16] kernel BUG at net/core/skbuff.c:2814! [ 549.186468] [ C16] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 549.186472] [ C16] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Kdump: loaded Not tainted 6.16.0-rc4+ #23 PREEMPT(voluntary) [ 549.186476] [ C16] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 549.186478] [ C16] RIP: 0010:__pskb_pull_tail+0x3ff/0x510 [ 549.186484] [ C16] Code: 06 f0 ff 4f 34 74 7b 4d 8b 8c 24 c8 00 00 00 45 8b 84 24 c0 00 00 00 e9 c8 fd ff ff 48 c7 44 24 08 00 00 00 00 e9 5e fe ff ff <0f> 0b 31 c0 e9 23 90 5b ff 41 f7 c6 ff 0f 00 00 75 bf 49 8b 06 a8 [ 549.186487] [ C16] RSP: 0018:ffffb391c0640d70 EFLAGS: 00010282 [ 549.186490] [ C16] RAX: 00000000fffffff2 RBX: ffff8fe7e4d40200 RCX: 00000000fffffff2 [ 549.186492] [ C16] RDX: ffff8fe7c3a4bf8e RSI: 0000000000000180 RDI: ffff8fe7c3a4bf40 [ 549.186494] [ C16] RBP: ffffb391c0640da8 R08: ffff8fe7c3a4c0c0 R09: 000000000000000e [ 549.186496] [ C16] R10: ffffb391c0640d88 R11: 000000000000000e R12: ffff8fe7e4d40200 [ 549.186497] [ C16] R13: 00000000fffffff2 R14: ffff8fe7fa01a000 R15: 00000000fffffff2 [ 549.186499] [ C16] FS: 0000000000000000(0000) GS:ffff8fef5ae40000(0000) knlGS:0000000000000000 [ 549.186502] [ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 549.186503] [ C16] CR2: 00007f77d81d6000 CR3: 000000051a032000 CR4: 0000000000750ef0 [ 549.186505] [ C16] PKRU: 55555554 [ 549.186507] [ C16] Call Trace: [ 549.186510] [ C16] [ 549.186513] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186517] [ C16] __skb_pad+0xc7/0xf0 [ 549.186523] [ C16] wx_clean_rx_irq+0x355/0x3b0 [libwx] [ 549.186533] [ C16] wx_poll+0x92/0x120 [libwx] [ 549.186540] [ C16] __napi_poll+0x28/0x190 [ 549.186544] [ C16] net_rx_action+0x301/0x3f0 [ 549.186548] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186551] [ C16] ? __raw_spin_lock_irqsave+0x1e/0x50 [ 549.186554] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186557] [ C16] ? wake_up_nohz_cpu+0x35/0x160 [ 549.186559] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186563] [ C16] handle_softirqs+0xf9/0x2c0 [ 549.186568] [ C16] __irq_exit_rcu+0xc7/0x130 [ 549.186572] [ C16] common_interrupt+0xb8/0xd0 [ 549.186576] [ C16] [ 549.186577] [ C16] [ 549.186579] [ C16] asm_common_interrupt+0x22/0x40 [ 549.186582] [ C16] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 549.186585] [ C16] Code: 00 00 e8 11 0e 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 0d ed 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 549.186587] [ C16] RSP: 0018:ffffb391c0277e78 EFLAGS: 00000246 [ 549.186590] [ C16] RAX: ffff8fef5ae40000 RBX: 0000000000000003 RCX: 0000000000000000 [ 549.186591] [ C16] RDX: 0000007fde0faac5 RSI: ffffffff826e53f6 RDI: ffffffff826fa9b3 [ 549.186593] [ C16] RBP: ffff8fe7c3a20800 R08: 0000000000000002 R09: 0000000000000000 [ 549.186595] [ C16] R10: 0000000000000000 R11: 000000000000ffff R12: ffffffff82ed7a40 [ 549.186596] [ C16] R13: 0000007fde0faac5 R14: 0000000000000003 R15: 0000000000000000 [ 549.186601] [ C16] ? cpuidle_enter_state+0xb3/0x420 [ 549.186605] [ C16] cpuidle_en ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38533", "url": "https://ubuntu.com/security/CVE-2025-38533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix the using of Rx buffer DMA The wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Althrough such error has not yet occurred, it is worth fixing in the code.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38490", "url": "https://ubuntu.com/security/CVE-2025-38490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: remove duplicate page_pool_put_full_page() page_pool_put_full_page() should only be invoked when freeing Rx buffers or building a skb if the size is too short. At other times, the pages need to be reused. So remove the redundant page put. In the original code, double free pages cause kernel panic: [ 876.949834] __irq_exit_rcu+0xc7/0x130 [ 876.949836] common_interrupt+0xb8/0xd0 [ 876.949838] [ 876.949838] [ 876.949840] asm_common_interrupt+0x22/0x40 [ 876.949841] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246 [ 876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000 [ 876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e [ 876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed [ 876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580 [ 876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000 [ 876.949852] ? cpuidle_enter_state+0xb3/0x420 [ 876.949855] cpuidle_enter+0x29/0x40 [ 876.949857] cpuidle_idle_call+0xfd/0x170 [ 876.949859] do_idle+0x7a/0xc0 [ 876.949861] cpu_startup_entry+0x25/0x30 [ 876.949862] start_secondary+0x117/0x140 [ 876.949864] common_startup_64+0x13e/0x148 [ 876.949867] [ 876.949868] ---[ end trace 0000000000000000 ]--- [ 876.949869] ------------[ cut here ]------------ [ 876.949870] list_del corruption, ffffead40445a348->next is NULL [ 876.949873] WARNING: CPU: 14 PID: 0 at lib/list_debug.c:52 __list_del_entry_valid_or_report+0x67/0x120 [ 876.949875] Modules linked in: snd_hrtimer(E) bnep(E) binfmt_misc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amd_atl(E) snd_hda_codec_realtek(E) intel_rapl_msr(E) snd_hda_codec_generic(E) intel_rapl_common(E) snd_hda_scodec_component(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) edac_mce_amd(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) amdxcp(E) kvm_amd(E) snd_hwdep(E) gpu_sched(E) drm_panel_backlight_quirks(E) cec(E) snd_pcm(E) drm_buddy(E) snd_seq_dummy(E) drm_ttm_helper(E) btusb(E) kvm(E) snd_seq_oss(E) btrtl(E) ttm(E) btintel(E) snd_seq_midi(E) btbcm(E) drm_exec(E) snd_seq_midi_event(E) i2c_algo_bit(E) snd_rawmidi(E) bluetooth(E) drm_suballoc_helper(E) irqbypass(E) snd_seq(E) ghash_clmulni_intel(E) sha512_ssse3(E) drm_display_helper(E) aesni_intel(E) snd_seq_device(E) rfkill(E) snd_timer(E) gf128mul(E) drm_client_lib(E) drm_kms_helper(E) snd(E) i2c_piix4(E) joydev(E) soundcore(E) wmi_bmof(E) ccp(E) k10temp(E) i2c_smbus(E) gpio_amdpt(E) i2c_designware_platform(E) gpio_generic(E) sg(E) [ 876.949914] i2c_designware_core(E) sch_fq_codel(E) parport_pc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) ip_tables(E) ext4 crc16 mbcache jbd2 sd_mod sfp mdio_i2c i2c_core txgbe ahci ngbe pcs_xpcs libahci libwx r8169 phylink libata realtek ptp pps_core video wmi [ 876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G W E 6.16.0-rc2+ #20 PREEMPT(voluntary) [ 876.949935] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE [ 876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 876.949936] RIP: 0010:__list_del_entry_valid_or_report+0x67/0x120 [ 876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff <0f> 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8 [ 876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282 [ 876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000 [ 876.949942] RDX: 0000000000000105 RSI: 00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38538", "url": "https://ubuntu.com/security/CVE-2025-38538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: nbpfaxi: Fix memory corruption in probe() The nbpf->chan[] array is allocated earlier in the nbpf_probe() function and it has \"num_channels\" elements. These three loops iterate one element farther than they should and corrupt memory. The changes to the second loop are more involved. In this case, we're copying data from the irqbuf[] array into the nbpf->chan[] array. If the data in irqbuf[i] is the error IRQ then we skip it, so the iterators are not in sync. I added a check to ensure that we don't go beyond the end of the irqbuf[] array. I'm pretty sure this can't happen, but it seemed harmless to add a check. On the other hand, after the loop has ended there is a check to ensure that the \"chan\" iterator is where we expect it to be. In the original code we went one element beyond the end of the array so the iterator wasn't in the correct place and it would always return -EINVAL. However, now it will always be in the correct place. I deleted the check since we know the result.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38493", "url": "https://ubuntu.com/security/CVE-2025-38493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/osnoise: Fix crash in timerlat_dump_stack() We have observed kernel panics when using timerlat with stack saving, with the following dmesg output: memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() constructs the ftrace stack entry like this: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; Since commit e7186af7fb26 (\"tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure\"), struct stack_entry marks its caller field with __counted_by(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow. Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to __ftrace_trace_stack().", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38539", "url": "https://ubuntu.com/security/CVE-2025-38539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Add down_write(trace_event_sem) when adding trace event When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values. If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel. The addition of the event should take the trace_event_sem for write while it adds the new event. Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38494", "url": "https://ubuntu.com/security/CVE-2025-38494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: do not bypass hid_hw_raw_request hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38495", "url": "https://ubuntu.com/security/CVE-2025-38495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: ensure the allocated report buffer can contain the reserved report ID When the report ID is not used, the low level transport drivers expect the first byte to be 0. However, currently the allocated buffer not account for that extra byte, meaning that instead of having 8 guaranteed bytes for implement to be working, we only have 7.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38496", "url": "https://ubuntu.com/security/CVE-2025-38496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-bufio: fix sched in atomic context If \"try_verify_in_tasklet\" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spin_lock_bh, the following warning is hit: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table \"0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 1 sha256 1 try_verify_in_tasklet\" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt]", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38497", "url": "https://ubuntu.com/security/CVE-2025-38497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Fix OOB read on empty string write When writing an empty string to either 'qw_sign' or 'landingPage' sysfs attributes, the store functions attempt to access page[l - 1] before validating that the length 'l' is greater than zero. This patch fixes the vulnerability by adding a check at the beginning of os_desc_qw_sign_store() and webusb_landingPage_store() to handle the zero-length input case gracefully by returning immediately.", "cve_priority": "medium", "cve_public_date": "2025-07-28 12:15:00 UTC" }, { "cve": "CVE-2025-38535", "url": "https://ubuntu.com/security/CVE-2025-38535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code assumed that the regulator should be disabled. However, if the regulator is marked as always-on, regulator_is_enabled() continues to return true, leading to an incorrect attempt to disable a regulator which is not enabled. This can result in warnings such as: [ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004 _regulator_disable+0xe4/0x1a0 [ 250.155652] unbalanced disables for VIN_SYS_5V0 To fix this, we move the regulator control logic into tegra186_xusb_padctl_id_override() function since it's directly related to the ID override state. The regulator is now only disabled when the role transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID register. This ensures that regulator enable/disable operations are properly balanced and only occur when actually transitioning to/from host mode.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38507", "url": "https://ubuntu.com/security/CVE-2025-38507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: avoid bluetooth suspend/resume stalls Ensure we don't stall or panic the kernel when using bluetooth-connected controllers. This was reported as an issue on android devices using kernel 6.6 due to the resume hook which had been added for usb joycons. First, set a new state value to JOYCON_CTLR_STATE_SUSPENDED in a newly-added nintendo_hid_suspend. This makes sure we will not stall out the kernel waiting for input reports during led classdev suspend. The stalls could happen if connectivity is unreliable or lost to the controller prior to suspend. Second, since we lose connectivity during suspend, do not try joycon_init() for bluetooth controllers in the nintendo_hid_resume path. Tested via multiple suspend/resume flows when using the controller both in USB and bluetooth modes.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38511", "url": "https://ubuntu.com/security/CVE-2025-38511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Clear all LMTT pages on alloc Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages. Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap. While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle. (cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38520", "url": "https://ubuntu.com/security/CVE-2025-38520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Don't call mmput from MMU notifier callback If the process is exiting, the mmput inside mmu notifier callback from compactd or fork or numa balancing could release the last reference of mm struct to call exit_mmap and free_pgtable, this triggers deadlock with below backtrace. The deadlock will leak kfd process as mmu notifier release is not called and cause VRAM leaking. The fix is to take mm reference mmget_non_zero when adding prange to the deferred list to pair with mmput in deferred list work. If prange split and add into pchild list, the pchild work_item.mm is not used, so remove the mm parameter from svm_range_unmap_split and svm_range_add_child. The backtrace of hung task: INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu] (cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38521", "url": "https://ubuntu.com/security/CVE-2025-38521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix kernel crash when hard resetting the GPU The GPU hard reset sequence calls pm_runtime_force_suspend() and pm_runtime_force_resume(), which according to their documentation should only be used during system-wide PM transitions to sleep states. The main issue though is that depending on some internal runtime PM state as seen by pm_runtime_force_suspend() (whether the usage count is <= 1), pm_runtime_force_resume() might not resume the device unless needed. If that happens, the runtime PM resume callback pvr_power_device_resume() is not called, the GPU clocks are not re-enabled, and the kernel crashes on the next attempt to access GPU registers as part of the power-on sequence. Replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume() with direct calls to the driver's runtime PM callbacks, pvr_power_device_suspend() and pvr_power_device_resume(), to ensure clocks are re-enabled and avoid the kernel crash.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38506", "url": "https://ubuntu.com/security/CVE-2025-38506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Allow CPU to reschedule while setting per-page memory attributes When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+), the host can experience CPU soft lockups when running an operation in kvm_vm_set_mem_attributes() to set memory attributes on the whole range of guest memory. watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372] CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary) Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024 RIP: 0010:xas_create+0x78/0x1f0 Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87 RSP: 0018:ffffad890a34b940 EFLAGS: 00000286 RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000 RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868 R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868 FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: xas_store+0x58/0x630 __xa_store+0xa5/0x130 xa_store+0x2c/0x50 kvm_vm_set_mem_attributes+0x343/0x710 [kvm] kvm_vm_ioctl+0x796/0xab0 [kvm] __x64_sys_ioctl+0xa3/0xd0 do_syscall_64+0x8c/0x7a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f5578d031bb Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b RBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000 R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120 R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0 While looping through the range of memory setting the attributes, call cond_resched() to give the scheduler a chance to run a higher priority task on the runqueue if necessary and avoid staying in kernel mode long enough to trigger the lockup.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38104", "url": "https://ubuntu.com/security/CVE-2025-38104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV RLCG Register Access is a way for virtual functions to safely access GPU registers in a virtualized environment., including TLB flushes and register reads. When multiple threads or VFs try to access the same registers simultaneously, it can lead to race conditions. By using the RLCG interface, the driver can serialize access to the registers. This means that only one thread can access the registers at a time, preventing conflicts and ensuring that operations are performed correctly. Additionally, when a low-priority task holds a mutex that a high-priority task needs, ie., If a thread holding a spinlock tries to acquire a mutex, it can lead to priority inversion. register access in amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical. The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being called, which attempts to acquire the mutex. This function is invoked from amdgpu_sriov_wreg, which in turn is called from gmc_v11_0_flush_gpu_tlb. The [ BUG: Invalid wait context ] indicates that a thread is trying to acquire a mutex while it is in a context that does not allow it to sleep (like holding a spinlock). Fixes the below: [ 253.013423] ============================= [ 253.013434] [ BUG: Invalid wait context ] [ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE [ 253.013464] ----------------------------- [ 253.013475] kworker/0:1/10 is trying to lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.013815] other info that might help us debug this: [ 253.013827] context-{4:4} [ 253.013835] 3 locks held by kworker/0:1/10: [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680 [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680 [ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024 [ 253.014224] Workqueue: events work_for_cpu_fn [ 253.014241] Call Trace: [ 253.014250] [ 253.014260] dump_stack_lvl+0x9b/0xf0 [ 253.014275] dump_stack+0x10/0x20 [ 253.014287] __lock_acquire+0xa47/0x2810 [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014562] ? __lock_acquire+0xa6b/0x2810 [ 253.014578] __mutex_lock+0x85/0xe20 [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014782] ? sched_clock_noinstr+0x9/0x10 [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014808] ? local_clock_noinstr+0xe/0xc0 [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.015029] mutex_lock_nested+0x1b/0x30 [ 253.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu] [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu] [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu] [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu] [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu] [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu] [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu] [ 253.0170 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-38067", "url": "https://ubuntu.com/security/CVE-2025-38067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rseq: Fix segfault on registration when rseq_cs is non-zero The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs. The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs. What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-37984", "url": "https://ubuntu.com/security/CVE-2025-37984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8): X / 8 + !!(X & 7) Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values. Additionally, use the macro in ecc_digits_from_bytes(), whose \"nbytes\" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs().", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-38437", "url": "https://ubuntu.com/security/CVE-2025-38437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potential use-after-free in oplock/lease break ack If ksmbd_iov_pin_rsp return error, use-after-free can happen by accessing opinfo->state and opinfo_put and ksmbd_fd_put could called twice.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38510", "url": "https://ubuntu.com/security/CVE-2025-38510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kasan: remove kasan_find_vm_area() to prevent possible deadlock find_vm_area() couldn't be called in atomic_context. If find_vm_area() is called to reports vm area information, kasan can trigger deadlock like: CPU0 CPU1 vmalloc(); alloc_vmap_area(); spin_lock(&vn->busy.lock) spin_lock_bh(&some_lock); spin_lock(&some_lock); kasan_report(); print_report(); print_address_description(); kasan_find_vm_area(); find_vm_area(); spin_lock(&vn->busy.lock) // deadlock! To prevent possible deadlock while kasan reports, remove kasan_find_vm_area().", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38503", "url": "https://ubuntu.com/security/CVE-2025-38503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix assertion when building free space tree When building the free space tree with the block group tree feature enabled, we can hit an assertion failure like this: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]--- This happens because we are processing an empty block group, which has no extents allocated from it, there are no items for this block group, including the block group item since block group items are stored in a dedicated tree when using the block group tree feature. It also means this is the block group with the highest start offset, so there are no higher keys in the extent root, hence btrfs_search_slot_for_read() returns 1 (no higher key found). Fix this by asserting 'ret' is 0 only if the block group tree feature is not enabled, in which case we should find a block group item for the block group since it's stored in the extent root and block group item keys are greater than extent item keys (the value for BTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and BTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively). In case 'ret' is 1, we just need to add a record to the free space tree which spans the whole block group, and we can achieve this by making 'ret == 0' as the while loop's condition.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38439", "url": "https://ubuntu.com/security/CVE-2025-38439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT When transmitting an XDP_REDIRECT packet, call dma_unmap_len_set() with the proper length instead of 0. This bug triggers this warning on a system with IOMMU enabled: WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170 RIP: 0010:__iommu_dma_unmap+0x159/0x170 Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45 b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ff22d31181150c88 EFLAGS: 00010206 RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000 R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000 R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00 FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0 PKRU: 55555554 Call Trace: ? show_regs+0x6d/0x80 ? __warn+0x89/0x160 ? __iommu_dma_unmap+0x159/0x170 ? report_bug+0x17e/0x1b0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x18/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? __iommu_dma_unmap+0x159/0x170 ? __iommu_dma_unmap+0xb3/0x170 iommu_dma_unmap_page+0x4f/0x100 dma_unmap_page_attrs+0x52/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? xdp_return_frame+0x2e/0xd0 bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en] __bnxt_poll_work_done+0x81/0x1e0 [bnxt_en] bnxt_poll+0xd3/0x1e0 [bnxt_en]", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38542", "url": "https://ubuntu.com/security/CVE-2025-38542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: Fix device refcount leak in atrtr_create() When updating an existing route entry in atrtr_create(), the old device reference was not being released before assigning the new device, leading to a device refcount leak. Fix this by calling dev_put() to release the old device reference before holding the new one.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38441", "url": "https://ubuntu.com/security/CVE-2025-38441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto() syzbot found a potential access to uninit-value in nf_flow_pppoe_proto() Blamed commit forgot the Ethernet header. BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5742 [inline] __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837 __netif_receive_skb_one_core net/core/dev.c:5975 [inline] __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090 netif_receive_skb_internal net/core/dev.c:6176 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6235 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xb4b/0x1580 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline]", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38443", "url": "https://ubuntu.com/security/CVE-2025-38443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix uaf in nbd_genl_connect() error path There is a use-after-free issue in nbd: block nbd6: Receive control failed (result -104) block nbd6: shutting down sockets ================================================================== BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022 Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67 CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: nbd6-recv recv_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 nbd_genl_connect() does not properly stop the device on certain error paths after nbd_start_device() has been called. This causes the error path to put nbd->config while recv_work continue to use the config after putting it, leading to use-after-free in recv_work. This patch moves nbd_start_device() after the backend file creation.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38444", "url": "https://ubuntu.com/security/CVE-2025-38444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: raid10: cleanup memleak at raid10_make_request If raid10_read_request or raid10_write_request registers a new request and the REQ_NOWAIT flag is set, the code does not free the malloc from the mempool. unreferenced object 0xffff8884802c3200 (size 192): comm \"fio\", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7e V4: changing backing tree to see if CKI tests will pass. The patch code has not changed between any versions.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38445", "url": "https://ubuntu.com/security/CVE-2025-38445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { \t// newpool is on the stack \tmempool_t newpool, oldpool; \t// initialize newpool.wait.head to stack address \tmempool_init(&newpool, ...); \tconf->r1bio_pool = newpool; } raid1_read_request() or raid1_write_request() { \talloc_r1bio() \t{ \t\tmempool_alloc() \t\t{ \t\t\t// if pool->alloc fails \t\t\tremove_element() \t\t\t{ \t\t\t\t--pool->curr_nr; \t\t\t} \t\t} \t} } mempool_free() { \tif (pool->curr_nr < pool->min_nr) { \t\t// pool->wait.head is a stack address \t\t// wake_up() will try to access this invalid address \t\t// which leads to a kernel panic \t\treturn; \t\twake_up(&pool->wait); \t} } Fix: reinit conf->r1bio_pool.wait after assigning newpool.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38543", "url": "https://ubuntu.com/security/CVE-2025-38543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: nvdec: Fix dma_alloc_coherent error check Check for NULL return value with dma_alloc_coherent, in line with Robin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38513", "url": "https://ubuntu.com/security/CVE-2025-38513", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev() There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For example, the following is possible: \tT0\t\t\t \t\tT1 zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { \t\t\t\t\t filter_ack() \t\t\t\t\t spin_lock_irqsave(&q->lock, flags); \t\t\t\t\t /* position == skb_queue_len(q) */ \t\t\t\t\t for (i=1; itype == NL80211_IFTYPE_AP) \t\t\t\t\t skb = __skb_dequeue(q); \t\t\t\t\t spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULL Since there is a small gap between checking skb queue length and skb being unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL. Then the pointer is passed to zd_mac_tx_status() where it is dereferenced. In order to avoid potential NULL pointer dereference due to situations like above, check if skb is not NULL before passing it to zd_mac_tx_status(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38448", "url": "https://ubuntu.com/security/CVE-2025-38448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Fix race condition in TTY wakeup A race condition occurs when gs_start_io() calls either gs_start_rx() or gs_start_tx(), as those functions briefly drop the port_lock for usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear port.tty and port_usb, respectively. Use the null-safe TTY Port helper function to wake up TTY. Example CPU1:\t\t\t CPU2: gserial_connect() // lock \t\t\t gs_close() // await lock gs_start_rx() // unlock usb_ep_queue() \t\t\t gs_close() // lock, reset port.tty and unlock gs_start_rx() // lock tty_wakeup() // NPE", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38515", "url": "https://ubuntu.com/security/CVE-2025-38515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Increment job count before swapping tail spsc queue A small race exists between spsc_queue_push and the run-job worker, in which spsc_queue_push may return not-first while the run-job worker has already idled due to the job count being zero. If this race occurs, job scheduling stops, leading to hangs while waiting on the job’s DMA fences. Seal this race by incrementing the job count before appending to the SPSC queue. This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in an SVM test case.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38449", "url": "https://ubuntu.com/security/CVE-2025-38449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Acquire references on GEM handles for framebuffers A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below. [ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]--- Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references. Commit 1a148af06000 (\"drm/gem-shmem: Use dma_buf from GEM object instance\") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before. v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38512", "url": "https://ubuntu.com/security/CVE-2025-38512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: prevent A-MSDU attacks in mesh networks This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks. This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt. This defense was tested with mac80211_hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field. It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented. Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation: https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38516", "url": "https://ubuntu.com/security/CVE-2025-38516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: qcom: msm: mark certain pins as invalid for interrupts On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: `gpiomon -c 0 113` on RB2. The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs. This function can be extended if we determine that there are more corner-cases like this.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38455", "url": "https://ubuntu.com/security/CVE-2025-38455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight Reject migration of SEV{-ES} state if either the source or destination VM is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the section between incrementing created_vcpus and online_vcpus. The bulk of vCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUs in parallel, and so sev_info.es_active can get toggled from false=>true in the destination VM after (or during) svm_vcpu_create(), resulting in an SEV{-ES} VM effectively having a non-SEV{-ES} vCPU. The issue manifests most visibly as a crash when trying to free a vCPU's NULL VMSA page in an SEV-ES VM, but any number of things can go wrong. BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 __fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]--- Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38456", "url": "https://ubuntu.com/security/CVE-2025-38456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:msghandler: Fix potential memory corruption in ipmi_create_user() The \"intf\" list iterator is an invalid pointer if the correct \"intf->intf_num\" is not found. Calling atomic_dec(&intf->nr_users) on and invalid pointer will lead to memory corruption. We don't really need to call atomic_dec() if we haven't called atomic_add_return() so update the if (intf->in_shutdown) path as well.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38514", "url": "https://ubuntu.com/security/CVE-2025-38514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix oops due to non-existence of prealloc backlog struct If an AF_RXRPC service socket is opened and bound, but calls are preallocated, then rxrpc_alloc_incoming_call() will oops because the rxrpc_backlog struct doesn't get allocated until the first preallocation is made. Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no backlog struct. This will cause the incoming call to be aborted.", "cve_priority": "medium", "cve_public_date": "2025-08-16 11:15:00 UTC" }, { "cve": "CVE-2025-38544", "url": "https://ubuntu.com/security/CVE-2025-38544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix bug due to prealloc collision When userspace is using AF_RXRPC to provide a server, it has to preallocate incoming calls and assign to them call IDs that will be used to thread related recvmsg() and sendmsg() together. The preallocated call IDs will automatically be attached to calls as they come in until the pool is empty. To the kernel, the call IDs are just arbitrary numbers, but userspace can use the call ID to hold a pointer to prepared structs. In any case, the user isn't permitted to create two calls with the same call ID (call IDs become available again when the call ends) and EBADSLT should result from sendmsg() if an attempt is made to preallocate a call with an in-use call ID. However, the cleanup in the error handling will trigger both assertions in rxrpc_cleanup_call() because the call isn't marked complete and isn't marked as having been released. Fix this by setting the call state in rxrpc_service_prealloc_one() and then marking it as being released before calling the cleanup function.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38457", "url": "https://ubuntu.com/security/CVE-2025-38457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Abort __tc_modify_qdisc if parent class does not exist Lion's patch [1] revealed an ancient bug in the qdisc API. Whenever a user creates/modifies a qdisc specifying as a parent another qdisc, the qdisc API will, during grafting, detect that the user is not trying to attach to a class and reject. However grafting is performed after qdisc_create (and thus the qdiscs' init callback) is executed. In qdiscs that eventually call qdisc_tree_reduce_backlog during init or change (such as fq, hhf, choke, etc), an issue arises. For example, executing the following commands: sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq Qdiscs such as fq, hhf, choke, etc unconditionally invoke qdisc_tree_reduce_backlog() in their control path init() or change() which then causes a failure to find the child class; however, that does not stop the unconditional invocation of the assumed child qdisc's qlen_notify with a null class. All these qdiscs make the assumption that class is non-null. The solution is ensure that qdisc_leaf() which looks up the parent class, and is invoked prior to qdisc_create(), should return failure on not finding the class. In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the parentid doesn't correspond to a class, so that we can detect it earlier on and abort before qdisc_create is called. [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38458", "url": "https://ubuntu.com/security/CVE-2025-38458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix NULL pointer dereference in vcc_sendmsg() atmarpd_dev_ops does not implement the send method, which may cause crash as bellow. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246 RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000 RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000 RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287 R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00 R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88 FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38459", "url": "https://ubuntu.com/security/CVE-2025-38459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix infinite recursive call of clip_push(). syzbot reported the splat below. [0] This happens if we call ioctl(ATMARP_MKIP) more than once. During the first call, clip_mkip() sets clip_push() to vcc->push(), and the second call copies it to clip_vcc->old_push(). Later, when the socket is close()d, vcc_destroy_socket() passes NULL skb to clip_push(), which calls clip_vcc->old_push(), triggering the infinite recursion. Let's prevent the second ioctl(ATMARP_MKIP) by checking vcc->user_back, which is allocated by the first call as clip_vcc. Note also that we use lock_sock() to prevent racy calls. [0]: BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000) Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00 RSP: 0018:ffffc9000d670000 EFLAGS: 00010246 RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000 RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300 R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0 Call Trace: clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 ... clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 vcc_destroy_socket net/atm/common.c:183 [inline] vcc_release+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff31c98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 Modules linked in:", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38546", "url": "https://ubuntu.com/security/CVE-2025-38546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix memory leak of struct clip_vcc. ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it to vcc->user_back. The code assumes that vcc_destroy_socket() passes NULL skb to vcc->push() when the socket is close()d, and then clip_push() frees clip_vcc. However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() in atm_init_atmarp(), resulting in memory leak. Let's serialise two ioctl() by lock_sock() and check vcc->push() in atm_init_atmarp() to prevent memleak.", "cve_priority": "medium", "cve_public_date": "2025-08-16 12:15:00 UTC" }, { "cve": "CVE-2025-38460", "url": "https://ubuntu.com/security/CVE-2025-38460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix potential null-ptr-deref in to_atmarpd(). atmarpd is protected by RTNL since commit f3a0592b37b8 (\"[ATM]: clip causes unregister hang\"). However, it is not enough because to_atmarpd() is called without RTNL, especially clip_neigh_solicit() / neigh_ops->solicit() is unsleepable. Also, there is no RTNL dependency around atmarpd. Let's use a private mutex and RCU to protect access to atmarpd in to_atmarpd().", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38461", "url": "https://ubuntu.com/security/CVE-2025-38461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_* TOCTOU Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer. This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38462", "url": "https://ubuntu.com/security/CVE-2025-38462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_{g2h,h2g} TOCTOU vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload. transport_{g2h,h2g} may become NULL after the NULL check. Introduce vsock_transport_local_cid() to protect from a potential null-ptr-deref. KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_find_cid+0x47/0x90 Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0 Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38463", "url": "https://ubuntu.com/security/CVE-2025-38463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtraction will result in copy holding a very large positive integer. In the subsequent logic, this large value is used to update sk->sk_forward_alloc, which can easily cause it to overflow. The syzkaller reproducer uses TCP_REPAIR to reliably create this condition. However, this can also occur in real-world scenarios. The tcp_bound_to_half_wnd() function can also reduce size_goal to a small value. This would cause the subsequent tcp_wmem_schedule() to set sk->sk_forward_alloc to a value close to INT_MAX. Further memory allocation requests would then cause sk_forward_alloc to wrap around and become negative. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38464", "url": "https://ubuntu.com/security/CVE-2025-38464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_conn_close(). syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0] tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn. The problem is that tipc_conn_close() is called after releasing the IDR lock. At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref. Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive. Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop(). [0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435 CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38465", "url": "https://ubuntu.com/security/CVE-2025-38465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: Fix wraparounds of sk->sk_rmem_alloc. Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) \tatomic_add(skb->truesize, &sk->sk_rmem_alloc); , which has the same problem fixed by commit 5a465a0da13e (\"udp: Fix multiple wraparounds of sk->sk_rmem_alloc.\"). For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition is always false as the two operands are of int. Then, a single socket can eat as many skb as possible until OOM happens, and we can see multiple wraparounds of sk->sk_rmem_alloc. Let's fix it by using atomic_add_return() and comparing the two variables as unsigned int. Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 * After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38466", "url": "https://ubuntu.com/security/CVE-2025-38466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Revert to requiring CAP_SYS_ADMIN for uprobes Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream. Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction. As such, require CAP_SYS_ADMIN for uprobes.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38467", "url": "https://ubuntu.com/security/CVE-2025-38467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling If there's support for another console device (such as a TTY serial), the kernel occasionally panics during boot. The panic message and a relevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...] Otherwise, the panics don't happen. This indicates that it's some sort of race condition. Add a check to validate if the drm device can handle vblanks before calling drm_crtc_handle_vblank() to avoid this.", "cve_priority": "medium", "cve_public_date": "2025-07-25 16:15:00 UTC" }, { "cve": "CVE-2025-38349", "url": "https://ubuntu.com/security/CVE-2025-38349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to \"ep_free(ep)\" until after it has unlocked the mutex. But it's wrong for the much subtler \"next to last\" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex \"unlock\" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: \t\"mutex_unlock() may access the mutex structure even after it has \t internally released the lock already - so it's not safe for \t another context to acquire the mutex and assume that the \t mutex_unlock() context is not using the structure anymore\" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).", "cve_priority": "medium", "cve_public_date": "2025-07-18 08:15:00 UTC" }, { "cve": "CVE-2025-38407", "url": "https://ubuntu.com/security/CVE-2025-38407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: cpu_ops_sbi: Use static array for boot_data Since commit 6b9f29b81b15 (\"riscv: Enable pcpu page first chunk allocator\"), if NUMA is enabled, the page percpu allocator may be used on very sparse configurations, or when requested on boot with percpu_alloc=page. In that case, percpu data gets put in the vmalloc area. However, sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data, and simply assumes that __pa() would work. This causes the just started hart to immediately access an invalid address and hang. Fortunately, struct sbi_hart_boot_data is not too large, so we can simply allocate an array for boot_data statically, putting it in the kernel image. This fixes NUMA=y SMP boot on Sophgo SG2042. To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then run with: qemu-system-riscv64 -M virt -smp 2 -nographic \\ -kernel arch/riscv/boot/Image \\ -append \"percpu_alloc=page\" Kernel output: [ 0.000000] Booting Linux on hartid 0 [ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025 ... [ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712 ... [ 0.083192] smp: Bringing up secondary CPUs ... [ 0.086722] ------------[ cut here ]------------ [ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080) [ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8 [ 0.088376] Modules linked in: [ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE [ 0.088833] Hardware name: riscv-virtio,qemu (DT) [ 0.088948] epc : __virt_to_phys+0xae/0xe8 [ 0.089001] ra : __virt_to_phys+0xae/0xe8 [ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0 [ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976 [ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0 [ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000 [ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000 [ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001 [ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec [ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000 [ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7 [ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8 [ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003 [ 0.090101] [] __virt_to_phys+0xae/0xe8 [ 0.090228] [] sbi_cpu_start+0x6e/0xe8 [ 0.090247] [] __cpu_up+0x1e/0x8c [ 0.090260] [] bringup_cpu+0x42/0x258 [ 0.090277] [] cpuhp_invoke_callback+0xe0/0x40c [ 0.090292] [] __cpuhp_invoke_callback_range+0x68/0xfc [ 0.090320] [] _cpu_up+0x11a/0x244 [ 0.090334] [] cpu_up+0x52/0x90 [ 0.090384] [] bringup_nonboot_cpus+0x78/0x118 [ 0.090411] [] smp_init+0x34/0xb8 [ 0.090425] [] kernel_init_freeable+0x148/0x2e4 [ 0.090442] [] kernel_init+0x1e/0x14c [ 0.090455] [] ret_from_fork_kernel+0xe/0xf0 [ 0.090471] [] ret_from_fork_kernel_asm+0x16/0x18 [ 0.090560] ---[ end trace 0000000000000000 ]--- [ 1.179875] CPU1: failed to come online [ 1.190324] smp: Brought up 1 node, 1 CPU", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38374", "url": "https://ubuntu.com/security/CVE-2025-38374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: optee: ffa: fix sleep in atomic context The OP-TEE driver registers the function notif_callback() for FF-A notifications. However, this function is called in an atomic context leading to errors like this when processing asynchronous notifications: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13 | Hardware name: linux,dummy-virt (DT) | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | optee_get_msg_arg+0x7c/0x21c | simple_call_with_arg+0x50/0xc0 | optee_do_bottom_half+0x14/0x20 | notif_callback+0x3c/0x48 | handle_notif_callbacks+0x9c/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 Fix this by adding work queue to process the notification in a non-atomic context.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38373", "url": "https://ubuntu.com/security/CVE-2025-38373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix potential deadlock in MR deregistration The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock. The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | → revoke_mr() | → mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | → mutex_lock(&dev->cache.rb_lock) | → mlx5r_cache_create_ent_locked() | → kzalloc(GFP_KERNEL) | → fs_reclaim() | → mmu_notifier_invalidate_range_start() | → mlx5_ib_invalidate_range() | → mutex_lock(&umem_odp->umem_mutex) → cache_ent_find_and_store() | → mutex_lock(&dev->cache.rb_lock) | Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex. Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path. This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path. The following lockdep warning demonstrates the deadlock: python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38408", "url": "https://ubuntu.com/security/CVE-2025-38408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38279", "url": "https://ubuntu.com/security/CVE-2025-38279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not include stack ptr register in precision backtracking bookkeeping Yi Lai reported an issue ([1]) where the following warning appears in kernel dmesg: [ 60.643604] verifier backtracking bug [ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 [ 60.648428] Modules linked in: bpf_testmod(OE) [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246 [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000 [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8 [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0 [ 60.691623] Call Trace: [ 60.692821] [ 60.693960] ? __pfx_verbose+0x10/0x10 [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ... Further analysis shows the warning is at line 4302 as below: 4294 /* static subprog call instruction, which 4295 * means that we are exiting current subprog, 4296 * so only r1-r5 could be still requested as 4297 * precise, r0 and r6-r10 or any stack slot in 4298 * the current frame should be zero by now 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env, \"BUG regs %x\\n\", bt_reg_mask(bt)); 4302 WARN_ONCE(1, \"verifier backtracking bug\"); 4303 return -EFAULT; 4304 } With the below test (also in the next patch): __used __naked static void __bpf_jmp_r10(void) { \tasm volatile ( \t\"r2 = 2314885393468386424 ll;\" \t\"goto +0;\" \t\"if r2 <= r10 goto +3;\" \t\"if r1 >= -1835016 goto +0;\" \t\"if r2 <= 8 goto +0;\" \t\"if r3 <= 0 goto +0;\" \t\"exit;\" \t::: __clobber_all); } SEC(\"?raw_tp\") __naked void bpf_jmp_r10(void) { \tasm volatile ( \t\"r3 = 0 ll;\" \t\"call __bpf_jmp_r10;\" \t\"r0 = 0;\" \t\"exit;\" \t::: __clobber_all); } The following is the verifier failure log: 0: (18) r3 = 0x0 ; R3_w=0 2: (85) call pc+2 caller: R10=fp0 callee: frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile (\" \\ @ verifier_precision.c:184 5: (18) r2 = 0x20202000256c6c78 ; frame1: R2_w=0x20202000256c6c78 7: (05) goto pc+0 8: (bd) if r2 <= r10 goto pc+3 ; frame1: R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1 mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 <= r10 goto pc+3 mark_preci ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38289", "url": "https://ubuntu.com/security/CVE-2025-38289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbk Smatch detected a potential use-after-free of an ndlp oject in dev_loss_tmo_callbk during driver unload or fatal error handling. Fix by reordering code to avoid potential use-after-free if initial nodelist reference has been previously removed.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38392", "url": "https://ubuntu.com/security/CVE-2025-38392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: convert control queue mutex to a spinlock With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated on module load: [ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578 [ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager [ 324.701689] preempt_count: 201, expected: 0 [ 324.701693] RCU nest depth: 0, expected: 0 [ 324.701697] 2 locks held by NetworkManager/1582: [ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0 [ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870 [ 324.701749] Preemption disabled at: [ 324.701752] [] __dev_open+0x3dd/0x870 [ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary) [ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022 [ 324.701774] Call Trace: [ 324.701777] [ 324.701779] dump_stack_lvl+0x5d/0x80 [ 324.701788] ? __dev_open+0x3dd/0x870 [ 324.701793] __might_resched.cold+0x1ef/0x23d <..> [ 324.701818] __mutex_lock+0x113/0x1b80 <..> [ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf] [ 324.701935] ? kasan_save_track+0x14/0x30 [ 324.701941] idpf_mb_clean+0x143/0x380 [idpf] <..> [ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf] [ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf] [ 324.702021] ? rcu_is_watching+0x12/0xc0 [ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf] <..> [ 324.702122] __hw_addr_sync_dev+0x1cf/0x300 [ 324.702126] ? find_held_lock+0x32/0x90 [ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf] [ 324.702152] __dev_open+0x3f8/0x870 [ 324.702159] ? __pfx___dev_open+0x10/0x10 [ 324.702174] __dev_change_flags+0x443/0x650 <..> [ 324.702208] netif_change_flags+0x80/0x160 [ 324.702218] do_setlink.isra.0+0x16a0/0x3960 <..> [ 324.702349] rtnl_newlink+0x12fd/0x21e0 The sequence is as follows: \trtnl_newlink()-> \t__dev_change_flags()-> \t__dev_open()-> \tdev_set_rx_mode() - > # disables BH and grabs \"dev->addr_list_lock\" \tidpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON \t__dev_uc_sync() -> \tidpf_add_mac_filter -> \tidpf_add_del_mac_filters -> \tidpf_send_mb_msg() -> \tidpf_mb_clean() -> \tidpf_ctlq_clean_sq() # mutex_lock(cq_lock) Fix by converting cq_lock to a spinlock. All operations under the new lock are safe except freeing the DMA memory, which may use vunmap(). Fix by requesting a contiguous physical memory for the DMA mapping.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38402", "url": "https://ubuntu.com/security/CVE-2025-38402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: return 0 size for RSS key if not supported Returning -EOPNOTSUPP from function returning u32 is leading to cast and invalid size value as a result. -EOPNOTSUPP as a size probably will lead to allocation fail. Command: ethtool -x eth0 It is visible on all devices that don't have RSS caps set. [ 136.615917] Call Trace: [ 136.615921] [ 136.615927] ? __warn+0x89/0x130 [ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330 [ 136.615953] ? report_bug+0x164/0x190 [ 136.615968] ? handle_bug+0x58/0x90 [ 136.615979] ? exc_invalid_op+0x17/0x70 [ 136.615987] ? asm_exc_invalid_op+0x1a/0x20 [ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330 [ 136.616028] __alloc_pages_noprof+0xe/0x20 [ 136.616038] ___kmalloc_large_node+0x80/0x110 [ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0 [ 136.616081] __kmalloc_noprof+0x32c/0x4c0 [ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616114] ethnl_default_doit+0x107/0x3d0 [ 136.616131] genl_family_rcv_msg_doit+0x100/0x160 [ 136.616147] genl_rcv_msg+0x1b8/0x2c0 [ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10 [ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10 [ 136.616176] netlink_rcv_skb+0x58/0x110 [ 136.616186] genl_rcv+0x28/0x40 [ 136.616195] netlink_unicast+0x19b/0x290 [ 136.616206] netlink_sendmsg+0x222/0x490 [ 136.616215] __sys_sendto+0x1fd/0x210 [ 136.616233] __x64_sys_sendto+0x24/0x30 [ 136.616242] do_syscall_64+0x82/0x160 [ 136.616252] ? __sys_recvmsg+0x83/0xe0 [ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210 [ 136.616275] ? do_syscall_64+0x8e/0x160 [ 136.616282] ? __count_memcg_events+0xa1/0x130 [ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30 [ 136.616306] ? handle_mm_fault+0xae/0x2d0 [ 136.616319] ? do_user_addr_fault+0x379/0x670 [ 136.616328] ? clear_bhb_loop+0x45/0xa0 [ 136.616340] ? clear_bhb_loop+0x45/0xa0 [ 136.616349] ? clear_bhb_loop+0x45/0xa0 [ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 136.616369] RIP: 0033:0x7fd30ba7b047 [ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44 [ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047 [ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003 [ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c [ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340 [ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38405", "url": "https://ubuntu.com/security/CVE-2025-38405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix memory leak of bio integrity If nvmet receives commands with metadata there is a continuous memory leak of kmalloc-128 slab or more precisely bio->bi_integrity. Since commit bf4c89fc8797 (\"block: don't call bio_uninit from bio_endio\") each user of bio_init has to use bio_uninit as well. Otherwise the bio integrity is not getting free. Nvmet uses bio_init for inline bios. Uninit the inline bio to complete deallocation of integrity in bio.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38388", "url": "https://ubuntu.com/security/CVE-2025-38388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It results in the below kernel warnings: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 To address this, replace the mutex with an rwlock to protect the notifier hashtable accesses. This ensures that read-side locking does not sleep and multiple readers can acquire the lock concurrently, avoiding unnecessary contention and potential deadlocks. Writer access remains exclusive, preserving correctness. This change resolves warnings from lockdep about potential sleep in atomic context.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38390", "url": "https://ubuntu.com/security/CVE-2025-38390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix memory leak by freeing notifier callback node Commit e0573444edbf (\"firmware: arm_ffa: Add interfaces to request notification callbacks\") adds support for notifier callbacks by allocating and inserting a callback node into a hashtable during registration of notifiers. However, during unregistration, the code only removes the node from the hashtable without freeing the associated memory, resulting in a memory leak. Resolve the memory leak issue by ensuring the allocated notifier callback node is properly freed after it is removed from the hashtable entry.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2024-36350", "url": "https://ubuntu.com/security/CVE-2024-36350", "cve_description": "A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information.", "cve_priority": "medium", "cve_public_date": "2025-07-08 17:15:00 UTC" }, { "cve": "CVE-2024-36357", "url": "https://ubuntu.com/security/CVE-2024-36357", "cve_description": "A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.", "cve_priority": "medium", "cve_public_date": "2025-07-08 17:15:00 UTC" }, { "cve": "CVE-2025-38376", "url": "https://ubuntu.com/security/CVE-2025-38376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume Shawn and John reported a hang issue during system suspend as below: - USB gadget is enabled as Ethernet - There is data transfer over USB Ethernet (scp a big file between host and device) - Device is going in/out suspend (echo mem > /sys/power/state) The root cause is the USB device controller is suspended but the USB bus is still active which caused the USB host continues to transfer data with device and the device continues to queue USB requests (in this case, a delayed TCP ACK packet trigger the issue) after controller is suspended, however the USB controller clock is already gated off. Then if udc driver access registers after that point, the system will hang. The correct way to avoid such issue is to disconnect device from host when the USB bus is not at suspend state. Then the host will receive disconnect event and stop data transfer in time. To continue make USB gadget device work after system resume, this will reconnect device automatically. To make usb wakeup work if USB bus is already at suspend state, this will keep connection for it only when USB device controller has enabled wakeup capability.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38396", "url": "https://ubuntu.com/security/CVE-2025-38396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass Export anon_inode_make_secure_inode() to allow KVM guest_memfd to create anonymous inodes with proper security context. This replaces the current pattern of calling alloc_anon_inode() followed by inode_init_security_anon() for creating security context manually. This change also fixes a security regression in secretmem where the S_PRIVATE flag was not cleared after alloc_anon_inode(), causing LSM/SELinux checks to be bypassed for secretmem file descriptors. As guest_memfd currently resides in the KVM module, we need to export this symbol for use outside the core kernel. In the future, guest_memfd might be moved to core-mm, at which point the symbols no longer would have to be exported. When/if that happens is still unclear.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38371", "url": "https://ubuntu.com/security/CVE-2025-38371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Disable interrupts before resetting the GPU Currently, an interrupt can be triggered during a GPU reset, which can lead to GPU hangs and NULL pointer dereference in an interrupt context as shown in the following trace: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Before resetting the G ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38384", "url": "https://ubuntu.com/security/CVE-2025-38384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: spinand: fix memory leak of ECC engine conf Memory allocated for the ECC engine conf is not released during spinand cleanup. Below kmemleak trace is seen for this memory leak: unreferenced object 0xffffff80064f00e0 (size 8): comm \"swapper/0\", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160 Fix the leak by calling nanddev_ecc_engine_cleanup() inside spinand_cleanup().", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38386", "url": "https://ubuntu.com/security/CVE-2025-38386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Refuse to evaluate a method if arguments are missing As reported in [1], a platform firmware update that increased the number of method parameters and forgot to update a least one of its callers, caused ACPICA to crash due to use-after-free. Since this a result of a clear AML issue that arguably cannot be fixed up by the interpreter (it cannot produce missing data out of thin air), address it by making ACPICA refuse to evaluate a method if the caller attempts to pass fewer arguments than expected to it.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38406", "url": "https://ubuntu.com/security/CVE-2025-38406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: remove WARN on bad firmware input If the firmware gives bad input, that's nothing to do with the driver's stack at this point etc., so the WARN_ON() doesn't add any value. Additionally, this is one of the top syzbot reports now. Just print a message, and as an added bonus, print the sizes too.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38399", "url": "https://ubuntu.com/security/CVE-2025-38399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port() The function core_scsi3_decode_spec_i_port(), in its error code path, unconditionally calls core_scsi3_lunacl_undepend_item() passing the dest_se_deve pointer, which may be NULL. This can lead to a NULL pointer dereference if dest_se_deve remains unset. SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg Unable to handle kernel paging request at virtual address dfff800000000012 Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod] Fix this by adding a NULL check before calling core_scsi3_lunacl_undepend_item()", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38409", "url": "https://ubuntu.com/security/CVE-2025-38409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix another leak in the submit error path put_unused_fd() doesn't free the installed file, if we've already done fd_install(). So we need to also free the sync_file. Patchwork: https://patchwork.freedesktop.org/patch/653583/", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38410", "url": "https://ubuntu.com/security/CVE-2025-38410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix a fence leak in submit error path In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Patchwork: https://patchwork.freedesktop.org/patch/653584/", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38377", "url": "https://ubuntu.com/security/CVE-2025-38377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rose: fix dangling neighbour pointers in rose_rt_device_down() There are two bugs in rose_rt_device_down() that can cause use-after-free: 1. The loop bound `t->count` is modified within the loop, which can cause the loop to terminate early and miss some entries. 2. When removing an entry from the neighbour array, the subsequent entries are moved up to fill the gap, but the loop index `i` is still incremented, causing the next entry to be skipped. For example, if a node has three neighbours (A, A, B) with count=3 and A is being removed, the second A is not checked. i=0: (A, A, B) -> (A, B) with count=2 ^ checked i=1: (A, B) -> (A, B) with count=2 ^ checked (B, not A!) i=2: (doesn't occur because i < count is false) This leaves the second A in the array with count=2, but the rose_neigh structure has been freed. Code that accesses these entries assumes that the first `count` entries are valid pointers, causing a use-after-free when it accesses the dangling pointer. Fix both issues by iterating over the array in reverse order with a fixed loop bound. This ensures that all entries are examined and that the removal of an entry doesn't affect subsequent iterations.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38389", "url": "https://ubuntu.com/security/CVE-2025-38389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix timeline left held on VMA alloc error The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform: <4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]--- If the test also unloads the i915 module then that's followed with: <3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915_vma_instance+0xee/0xc10 [i915] <4> [357.789290] init_status_page+0x7b/0x420 [i915] <4> [357.789532] intel_engines_init+0x1d8/0x980 [i915] <4> [357.789772] intel_gt_init+0x175/0x450 [i915] <4> [357.790014] i915_gem_init+0x113/0x340 [i915] <4> [357.790281] i915_driver_probe+0x847/0xed0 [i915] <4> [357.790504] i915_pci_probe+0xe6/0x220 [i915] ... Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - igt@api_intel_allocator@fork-simple-stress-signal, - igt@api_intel_allocator@two-level-inception-interruptible, - igt@gem_linear_blits@interruptible, - igt@prime_mmap_coherency@ioctl-errors, which invisibly trigger the issue, then exhibited with first driver unbind attempt. All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring submission, in particular. If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error. In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915_vma_instance() called from inside is interrupted with a signal, then ring_context_alloc() fails, leaving the timeline held referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind. Get the legacy timeline only after successful allocation of the context engine's VMA. v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue. (cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38385", "url": "https://ubuntu.com/security/CVE-2025-38385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect Remove redundant netif_napi_del() call from disconnect path. A WARN may be triggered in __netif_napi_del_locked() during USB device disconnect: WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 This happens because netif_napi_del() is called in the disconnect path while NAPI is still enabled. However, it is not necessary to call netif_napi_del() explicitly, since unregister_netdev() will handle NAPI teardown automatically and safely. Removing the redundant call avoids triggering the warning. Full trace: lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV lan78xx 1-1:1.0 enu1: Link is Down lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 Modules linked in: flexcan can_dev fuse CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT Hardware name: SKOV IMX8MP CPU revC - bd500 (DT) Workqueue: usb_hub_wq hub_event pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __netif_napi_del_locked+0x2b4/0x350 lr : __netif_napi_del_locked+0x7c/0x350 sp : ffffffc085b673c0 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000 Call trace: __netif_napi_del_locked+0x2b4/0x350 (P) lan78xx_disconnect+0xf4/0x360 usb_unbind_interface+0x158/0x718 device_remove+0x100/0x150 device_release_driver_internal+0x308/0x478 device_release_driver+0x1c/0x30 bus_remove_device+0x1a8/0x368 device_del+0x2e0/0x7b0 usb_disable_device+0x244/0x540 usb_disconnect+0x220/0x758 hub_event+0x105c/0x35e0 process_one_work+0x760/0x17b0 worker_thread+0x768/0xce8 kthread+0x3bc/0x690 ret_from_fork+0x10/0x20 irq event stamp: 211604 hardirqs last enabled at (211603): [] _raw_spin_unlock_irqrestore+0x84/0x98 hardirqs last disabled at (211604): [] el1_dbg+0x24/0x80 softirqs last enabled at (211296): [] handle_softirqs+0x820/0xbc8 softirqs last disabled at (210993): [] __do_softirq+0x18/0x20 ---[ end trace 0000000000000000 ]--- lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38412", "url": "https://ubuntu.com/security/CVE-2025-38412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38382", "url": "https://ubuntu.com/security/CVE-2025-38382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix iteration of extrefs during log replay At __inode_add_ref() when processing extrefs, if we jump into the next label we have an undefined value of victim_name.len, since we haven't initialized it before we did the goto. This results in an invalid memory access in the next iteration of the loop since victim_name.len was not initialized to the length of the name of the current extref. Fix this by initializing victim_name.len with the current extref's name length.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38393", "url": "https://ubuntu.com/security/CVE-2025-38393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero. It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f (\"SUNRPC: Fix a race to wake a sync task\"). Fix it up by applying the advised barrier.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38400", "url": "https://ubuntu.com/security/CVE-2025-38400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails. syzbot reported a warning below [1] following a fault injection in nfs_fs_proc_net_init(). [0] When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed. Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning is logged as the directory is not empty. Let's handle the error of nfs_fs_proc_net_init() properly. [0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174) should_failslab (mm/failslab.c:46) kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204) __proc_create (fs/proc/generic.c:427) proc_create_reg (fs/proc/generic.c:554) proc_create_net_data (fs/proc/proc_net.c:120) nfs_fs_proc_net_init (fs/nfs/client.c:1409) nfs_net_init (fs/nfs/inode.c:2600) ops_init (net/core/net_namespace.c:138) setup_net (net/core/net_namespace.c:443) copy_net_ns (net/core/net_namespace.c:576) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4)) ksys_unshare (kernel/fork.c:3123) __x64_sys_unshare (kernel/fork.c:3190) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) [1]: remove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs' WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727 Modules linked in: CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727 Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00 RSP: 0018:ffffc90003637b08 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8 RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001 RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00 R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000 FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76 ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253 setup_net+0x2e1/0x510 net/core/net_namespace.c:457 copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574 create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218 ksys_unshare+0x45b/0xa40 kernel/fork.c:3121 __do_sys_unshare kernel/fork.c:3192 [inline] __se_sys_unshare kernel/fork.c:3190 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa1a6b8e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38387", "url": "https://ubuntu.com/security/CVE-2025-38387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insert The obj_event may be loaded immediately after inserted, then if the list_head is not initialized then we may get a poisonous pointer. This fixes the crash below: mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E) [last unloaded: mst_pci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatch_event_fd+0x68/0x300 [mlx5_ib] lr : devx_event_notifier+0xcc/0x228 [mlx5_ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatch_event_fd+0x68/0x300 [mlx5_ib] devx_event_notifier+0xcc/0x228 [mlx5_ib] atomic_notifier_call_chain+0x58/0x80 mlx5_eq_async_int+0x148/0x2b0 [mlx5_core] atomic_notifier_call_chain+0x58/0x80 irq_int_handler+0x20/0x30 [mlx5_core] __handle_irq_event_percpu+0x60/0x220 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x58/0x158 handle_fasteoi_irq+0xfc/0x188 generic_handle_irq+0x34/0x48 ...", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38401", "url": "https://ubuntu.com/security/CVE-2025-38401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtk-sd: Prevent memory corruption from DMA map failure If msdc_prepare_data() fails to map the DMA region, the request is not prepared for data receiving, but msdc_start_data() proceeds the DMA with previous setting. Since this will lead a memory corruption, we have to stop the request operation soon after the msdc_prepare_data() fails to prepare it.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38391", "url": "https://ubuntu.com/security/CVE-2025-38391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: do not index invalid pin_assignments A poorly implemented DisplayPort Alt Mode port partner can indicate that its pin assignment capabilities are greater than the maximum value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show will cause a BRK exception due to an out of bounds array access. Prevent for loop in pin_assignment_show from accessing invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop condition.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38395", "url": "https://ubuntu.com/security/CVE-2025-38395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But the memory is allocated for only one pointer. This will lead to out-of-bounds access later in the code if 'config::ngpios' is > 1. So fix the code to allocate enough memory to hold 'config::ngpios' of GPIO descriptors. While at it, also move the check for memory allocation failure to be below the allocation to make it more readable.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38403", "url": "https://ubuntu.com/security/CVE-2025-38403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: Clear the vmci transport packet properly when initializing it In vmci_transport_packet_init memset the vmci_transport_packet before populating the fields to avoid any uninitialised data being left in the structure.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38375", "url": "https://ubuntu.com/security/CVE-2025-38375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: ensure the received length does not exceed allocated size In xdp_linearize_page, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-37842", "url": "https://ubuntu.com/security/CVE-2025-37842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl-qspi: use devm function instead of driver remove Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence. Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23155", "url": "https://ubuntu.com/security/CVE-2025-23155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix accessing freed irq affinity_hint In stmmac_request_irq_multi_msi(), a pointer to the stack variable cpu_mask is passed to irq_set_affinity_hint(). This value is stored in irq_desc->affinity_hint, but once stmmac_request_irq_multi_msi() returns, the pointer becomes dangling. The affinity_hint is exposed via procfs with S_IRUGO permissions, allowing any unprivileged process to read it. Accessing this stale pointer can lead to: - a kernel oops or panic if the referenced memory has been released and unmapped, or - leakage of kernel data into userspace if the memory is re-used for other purposes. All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are affected.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-22101", "url": "https://ubuntu.com/security/CVE-2025-22101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix Tx L4 checksum The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol. There was a bug to set Tx checksum flag for the other protocol that results in Tx ring hang. Fix to compute software checksum for these packets.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38361", "url": "https://ubuntu.com/security/CVE-2025-38361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38364", "url": "https://ubuntu.com/security/CVE-2025-38364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate() Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations. The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption. User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least)", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38246", "url": "https://ubuntu.com/security/CVE-2025-38246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: properly flush XDP redirect lists We encountered following crash when testing a XDP_REDIRECT feature in production: [56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cut here ]------------ [56251.611357] kernel BUG at lib/list_debug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] [56251.851943] cpu_map_enqueue.cold+0x5/0xa [56251.860243] xdp_do_redirect+0x2d9/0x480 [56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en] [56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en] [56251.885665] ? cpu_max_write+0x1e/0x100 [56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en] [56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en] [56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.944250] __napi_poll+0x2b/0x160 [56251.951155] bpf_trampoline_6442548651+0x79/0x123 [56251.959262] __napi_poll+0x5/0x160 [56251.966037] net_rx_action+0x3d2/0x880 [56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.989262] ? __hrtimer_run_queues+0x162/0x2a0 [56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en] [56252.019903] handle_softirqs+0xcf/0x270 [56252.026650] irq_exit_rcu+0x67/0x90 [56252.032933] common_interrupt+0x85/0xa0 [56252.039498] [56252.044246] [56252.048935] asm_common_interrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidle_enter_state+0xab/0x420 [56252.153909] cpuidle_enter+0x2d/0x40 [56252.160360] do_idle+0x176/0x1c0 [56252.166456 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38250", "url": "https://ubuntu.com/security/CVE-2025-38250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 (\"Bluetooth: Remove unused hci-destruct cb\"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38253", "url": "https://ubuntu.com/security/CVE-2025-38253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix crash in wacom_aes_battery_handler() Commit fd2a9b29dc9c (\"HID: wacom: Remove AES power_supply after extended inactivity\") introduced wacom_aes_battery_handler() which is scheduled as a delayed work (aes_battery_work). In wacom_remove(), aes_battery_work is not canceled. Consequently, if the device is removed while aes_battery_work is still pending, then hard crashes or \"Oops: general protection fault...\" are experienced when wacom_aes_battery_handler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aes_battery_work was still pending at the time of hibernation. So, take care to cancel aes_battery_work in wacom_remove().", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38264", "url": "https://ubuntu.com/security/CVE-2025-38264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: sanitize request list handling Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38362", "url": "https://ubuntu.com/security/CVE-2025-38362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null pointer check for get_first_active_display() The function mod_hdcp_hdcp1_enable_encryption() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference in mod_hdcp_hdcp2_enable_encryption(). Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38354", "url": "https://ubuntu.com/security/CVE-2025-38354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/gpu: Fix crash when throttling GPU immediately during boot There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ... At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 (\"drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy\"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msm_devfreq_get_dev_status() will end up accessing GMU registers, causing the crash. Fix this by setting df->suspended correctly during initialization. Patchwork: https://patchwork.freedesktop.org/patch/650772/", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38363", "url": "https://ubuntu.com/security/CVE-2025-38363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix a possible null pointer dereference In tegra_crtc_reset(), new memory is allocated with kzalloc(), but no check is performed. Before calling __drm_atomic_helper_crtc_reset, state should be checked to prevent possible null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38239", "url": "https://ubuntu.com/security/CVE-2025-38239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38365", "url": "https://ubuntu.com/security/CVE-2025-38365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a race between renames and directory logging We have a race between a rename and directory inode logging that if it happens and we crash/power fail before the rename completes, the next time the filesystem is mounted, the log replay code will end up deleting the file that was being renamed. This is best explained following a step by step analysis of an interleaving of steps that lead into this situation. Consider the initial conditions: 1) We are at transaction N; 2) We have directories A and B created in a past transaction (< N); 3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as \"A/foo_link1\" and \"B/foo_link2\". Both hard links were persisted in a past transaction (< N); 4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as \"A/bar\". This file was also persisted in a past transaction (< N). The steps leading to a file loss are the following and for all of them we are under transaction N: 1) Link \"A/foo_link1\" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from \"A/bar\" to \"A/baz\", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry \"A/baz\" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name \"A/bar\" nor for the new name \"A/baz\" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree; 10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name \"A/bar\", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to \"A/bar\"). Since there's no other hard link for inode Y and the log replay code deletes the name \"A/bar\", the file is lost. The issue wouldn't happen if task B synced the log only after task A called btrfs_log_new_name(), which would update the log with the new name for inode Y (\"A/bar\"). Fix this by pinning the log root during renames before removing the old directory entry, and unpinning af ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38244", "url": "https://ubuntu.com/security/CVE-2025-38244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when reconnecting channels Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W ------------------------------------------------------ cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200 but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK *** 3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38245", "url": "https://ubuntu.com/security/CVE-2025-38245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister(). syzbot reported a warning below during atm_dev_register(). [0] Before creating a new device and procfs/sysfs for it, atm_dev_register() looks up a duplicated device by __atm_dev_lookup(). These operations are done under atm_dev_mutex. However, when removing a device in atm_dev_deregister(), it releases the mutex just after removing the device from the list that __atm_dev_lookup() iterates over. So, there will be a small race window where the device does not exist on the device list but procfs/sysfs are still not removed, triggering the splat. Let's hold the mutex until procfs/sysfs are removed in atm_dev_deregister(). [0]: proc_dir_entry 'atm/atmtcp:0' already registered WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377 Modules linked in: CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377 Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48 RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248 RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001 RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140 R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444 FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f38b3b74459 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459 RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005 RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b ", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38249", "url": "https://ubuntu.com/security/CVE-2025-38249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() In snd_usb_get_audioformat_uac3(), the length value returned from snd_usb_ctl_msg() is used directly for memory allocation without validation. This length is controlled by the USB device. The allocated buffer is cast to a uac3_cluster_header_descriptor and its fields are accessed without verifying that the buffer is large enough. If the device returns a smaller than expected length, this leads to an out-of-bounds read. Add a length check to ensure the buffer is large enough for uac3_cluster_header_descriptor.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38251", "url": "https://ubuntu.com/security/CVE-2025-38251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: clip: prevent NULL deref in clip_push() Blamed commit missed that vcc_destroy_socket() calls clip_push() with a NULL skb. If clip_devs is NULL, clip_push() then crashes when reading skb->truesize.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38255", "url": "https://ubuntu.com/security/CVE-2025-38255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly() While testing null_blk with configfs, echo 0 > poll_queues will trigger following panic: BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__bitmap_or+0x48/0x70 Call Trace: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from kcalloc(), and later ZERO_SIZE_PTR will be deferenced. Fix the problem by checking numgrps first in group_cpus_evenly(), and return NULL directly if numgrps is zero. [yukuai3@huawei.com: also fix the non-SMP version]", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38257", "url": "https://ubuntu.com/security/CVE-2025-38257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Prevent overflow in size calculation for memdup_user() Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow. In this case the actual size of the allocated area and the value describing it won't be in sync leading to various types of unpredictable behaviour later. Use a proper memdup_array_user() helper which returns an error if an overflow is detected. Note that it is different from when nr_apqns is initially zero - that case is considered valid and should be handled in subsequent pkey_handler implementations. Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38258", "url": "https://ubuntu.com/security/CVE-2025-38258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write memcg_path_store() assigns a newly allocated memory buffer to filter->memcg_path, without deallocating the previously allocated and assigned memory buffer. As a result, users can leak kernel memory by continuously writing a data to memcg_path DAMOS sysfs file. Fix the leak by deallocating the previously set memory buffer.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38259", "url": "https://ubuntu.com/security/CVE-2025-38259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38230", "url": "https://ubuntu.com/security/CVE-2025-38230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: validate AG parameters in dbMount() to prevent crashes Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch corrupted metadata early and avoid undefined behavior in dbAllocAG. Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE: - agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0. - agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0. - agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8). UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9 shift exponent -335544310 is negative CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38260", "url": "https://ubuntu.com/security/CVE-2025-38260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: handle csum tree error with rescue=ibadroots correctly [BUG] There is syzbot based reproducer that can crash the kernel, with the following call trace: (With some debug output added) DEBUG: rescue=ibadroots parsed BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010) BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8 BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm BTRFS info (device loop0): using free-space-tree BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0 DEBUG: read tree root path failed for tree csum, ret=-5 BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0 BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0 process 'repro' launched './file2' with NULL argv: empty string added DEBUG: no csum root, idatacsums=0 ibadroots=134217728 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs] Call Trace: btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs] btrfs_submit_bbio+0x43e/0x1a80 [btrfs] submit_one_bio+0xde/0x160 [btrfs] btrfs_readahead+0x498/0x6a0 [btrfs] read_pages+0x1c3/0xb20 page_cache_ra_order+0x4b5/0xc20 filemap_get_pages+0x2d3/0x19e0 filemap_read+0x314/0xde0 __kernel_read+0x35b/0x900 bprm_execve+0x62e/0x1140 do_execveat_common.isra.0+0x3fc/0x520 __x64_sys_execveat+0xdc/0x130 do_syscall_64+0x54/0x1d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- [CAUSE] Firstly the fs has a corrupted csum tree root, thus to mount the fs we have to go \"ro,rescue=ibadroots\" mount option. Normally with that mount option, a bad csum tree root should set BTRFS_FS_STATE_NO_DATA_CSUMS flag, so that any future data read will ignore csum search. But in this particular case, we have the following call trace that caused NULL csum root, but not setting BTRFS_FS_STATE_NO_DATA_CSUMS: load_global_roots_objectid(): \t\tret = btrfs_search_slot(); \t\t/* Succeeded */ \t\tbtrfs_item_key_to_cpu() \t\tfound = true; \t\t/* We found the root item for csum tree. */ \t\troot = read_tree_root_path(); \t\tif (IS_ERR(root)) { \t\t\tif (!btrfs_test_opt(fs_info, IGNOREBADROOTS)) \t\t\t/* \t\t\t * Since we have rescue=ibadroots mount option, \t\t\t * @ret is still 0. \t\t\t */ \t\t\tbreak; \tif (!found || ret) { \t\t/* @found is true, @ret is 0, error handling for csum \t\t * tree is skipped. \t\t */ \t} This means we completely skipped to set BTRFS_FS_STATE_NO_DATA_CSUMS if the csum tree is corrupted, which results unexpected later csum lookup. [FIX] If read_tree_root_path() failed, always populate @ret to the error number. As at the end of the function, we need @ret to determine if we need to do the extra error handling for csum tree.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38262", "url": "https://ubuntu.com/security/CVE-2025-38262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: uartlite: register uart driver in init When two instances of uart devices are probing, a concurrency race can occur. If one thread calls uart_register_driver function, which first allocates and assigns memory to 'uart_state' member of uart_driver structure, the other instance can bypass uart driver registration and call ulite_assign. This calls uart_add_one_port, which expects the uart driver to be fully initialized. This leads to a kernel panic due to a null pointer dereference: [ 8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8 [ 8.156982] #PF: supervisor write access in kernel mode [ 8.156984] #PF: error_code(0x0002) - not-present page [ 8.156986] PGD 0 P4D 0 ... [ 8.180668] RIP: 0010:mutex_lock+0x19/0x30 [ 8.188624] Call Trace: [ 8.188629] ? __die_body.cold+0x1a/0x1f [ 8.195260] ? page_fault_oops+0x15c/0x290 [ 8.209183] ? __irq_resolve_mapping+0x47/0x80 [ 8.209187] ? exc_page_fault+0x64/0x140 [ 8.209190] ? asm_exc_page_fault+0x22/0x30 [ 8.209196] ? mutex_lock+0x19/0x30 [ 8.223116] uart_add_one_port+0x60/0x440 [ 8.223122] ? proc_tty_register_driver+0x43/0x50 [ 8.223126] ? tty_register_driver+0x1ca/0x1e0 [ 8.246250] ulite_probe+0x357/0x4b0 [uartlite] To prevent it, move uart driver registration in to init function. This will ensure that uart_driver is always registered when probe function is called.", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38368", "url": "https://ubuntu.com/security/CVE-2025-38368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe() The returned value, pfsm->miscdev.name, from devm_kasprintf() could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 (\"ice: Fix some null pointer dereference issues in ice_ptp.c\"). This issue is found by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38436", "url": "https://ubuntu.com/security/CVE-2025-38436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/scheduler: signal scheduled fence when kill job When an entity from application B is killed, drm_sched_entity_kill() removes all jobs belonging to that entity through drm_sched_entity_kill_jobs_work(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared. This leads to application A hanging indefinitely while waiting for a dependency that will never be resolved. Fix this issue by ensuring that scheduled fences are properly signaled when an entity is killed, allowing dependent applications to continue execution.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38263", "url": "https://ubuntu.com/security/CVE-2025-38263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix NULL pointer in cache_set_flush() 1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc(). 2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set(). 3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue(\"bcache_gc\", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 } (1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885). (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return. (3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL. LINE#1624 - LINE#1665 is some codes about function of cache_set_flush(). As (1), in LINE#1885 call bch_cache_set_unregister() ---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 } (4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below: [ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory [ 846.713242] bcache: register_bcache() error : failed to register device [ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered [ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8 [ 846.714790] PGD 0 P4D 0 [ 846.715129] Oops: 0000 [#1] SMP PTI [ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1 [ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018 [ 846.716451] Workqueue: events cache_set_flush [bcache] [ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache] [ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38369", "url": "https://ubuntu.com/security/CVE-2025-38369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated. This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point. In this case, when the user driver detaches, the WQ is destroyed but it still calls destroy_workqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists.", "cve_priority": "medium", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-22128", "url": "https://ubuntu.com/security/CVE-2025-22128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath12k_pci_msi_alloc(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This may end up with a warning from the IRQ core that is expecting the affinity hint to be cleared before freeing the IRQ: kernel/irq/manage.c: \t/* make sure affinity_hint is cleaned up */ \tif (WARN_ON_ONCE(desc->affinity_hint)) \t\tdesc->affinity_hint = NULL; So to fix this issue, clear the IRQ affinity hint before calling ath12k_pci_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38333", "url": "https://ubuntu.com/security/CVE-2025-38333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to bail out in get_new_segment() ------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20 get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38210", "url": "https://ubuntu.com/security/CVE-2025-38210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs-tsm-report: Fix NULL dereference of tsm_ops Unlike sysfs, the lifetime of configfs objects is controlled by userspace. There is no mechanism for the kernel to find and delete all created config-items. Instead, the configfs-tsm-report mechanism has an expectation that tsm_unregister() can happen at any time and cause established config-item access to start failing. That expectation is not fully satisfied. While tsm_report_read(), tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail if tsm_ops have been unregistered, tsm_report_privlevel_store() tsm_report_provider_show() fail to check for ops registration. Add the missing checks for tsm_ops having been removed. Now, in supporting the ability for tsm_unregister() to always succeed, it leaves the problem of what to do with lingering config-items. The expectation is that the admin that arranges for the ->remove() (unbind) of the ${tsm_arch}-guest driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bind) of the ${tsm_arch}-guest driver fails. This allows for emergency shutdown / revocation of attestation interfaces, and requires coordinated restart.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38232", "url": "https://ubuntu.com/security/CVE-2025-38232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38320", "url": "https://ubuntu.com/security/CVE-2025-38320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] __se_sys_clone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] dup_task_struct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before: commit d93a855c31b7 (\"s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()\") As described in that commit, regs_get_kernel_stack_nth() has confirmed that `addr` is on the stack, so reading the value at `*addr` should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case. [will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38424", "url": "https://ubuntu.com/security/CVE-2025-38424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Fix sample vs do_exit() Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons. Flip this order by moving up where we stop perf in do_exit(). Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER to abort when the current task does not have an mm (exit_mm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38321", "url": "https://ubuntu.com/security/CVE-2025-38321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: Log an error when close_all_cached_dirs fails Under low-memory conditions, close_all_cached_dirs() can't move the dentries to a separate list to dput() them once the locks are dropped. This will result in a \"Dentry still in use\" error, so add an error message that makes it clear this is what happened: [ 495.281119] CIFS: VFS: \\\\otters.example.com\\share Out of memory while dropping dentries [ 495.281595] ------------[ cut here ]------------ [ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs] [ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0 Also, bail out of looping through all tcons as soon as a single allocation fails, since we're already in trouble, and kmalloc() attempts for subseqeuent tcons are likely to fail just like the first one did.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38180", "url": "https://ubuntu.com/security/CVE-2025-38180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: fix /proc/net/atm/lec handling /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls without prior dev_hold(), leading to imbalance and UAF.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38323", "url": "https://ubuntu.com/security/CVE-2025-38323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: add lec_mutex syzbot found its way in net/atm/lec.c, and found an error path in lecd_attach() could leave a dangling pointer in dev_lec[]. Add a mutex to protect dev_lecp[] uses from lecd_attach(), lec_vcc_attach() and lec_mcast_attach(). Following patch will use this mutex for /proc/net/atm/lec. BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline] BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142 CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xcd/0x680 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 lecd_attach net/atm/lec.c:751 [inline] lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4328 [inline] __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015 alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711 lecd_attach net/atm/lec.c:737 [inline] lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x2b4/0x4d0 mm/slub.c:4842 free_netdev+0x6c5/0x910 net/core/dev.c:11892 lecd_attach net/atm/lec.c:744 [inline] lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38181", "url": "https://ubuntu.com/security/CVE-2025-38181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: calipso: Fix null-ptr-deref in calipso_req_{set,del}attr(). syzkaller reported a null-ptr-deref in sock_omalloc() while allocating a CALIPSO option. [0] The NULL is of struct sock, which was fetched by sk_to_full_sk() in calipso_req_setattr(). Since commit a1a5344ddbe8 (\"tcp: avoid two atomic ops for syncookies\"), reqsk->rsk_listener could be NULL when SYN Cookie is returned to its client, as hinted by the leading SYN Cookie log. Here are 3 options to fix the bug: 1) Return 0 in calipso_req_setattr() 2) Return an error in calipso_req_setattr() 3) Alaways set rsk_listener 1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie for CALIPSO. 3) is also no go as there have been many efforts to reduce atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35 (\"tcp/dccp: do not touch listener sk_refcnt under synflood\"). As of the blamed commit, SYN Cookie already did not need refcounting, and no one has stumbled on the bug for 9 years, so no CALIPSO user will care about SYN Cookie. Let's return an error in calipso_req_setattr() and calipso_req_delattr() in the SYN Cookie case. This can be reproduced by [1] on Fedora and now connect() of nc times out. [0]: TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806 Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b RSP: 0018:ffff88811af89038 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400 RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030 RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000 R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050 FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551 security_inet_conn_request+0x50/0xa0 security/security.c:4945 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:469 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netf ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38182", "url": "https://ubuntu.com/security/CVE-2025-38182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: santizize the arguments from userspace when adding a device Sanity check the values for queue depth and number of queues we get from userspace when adding a device.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38183", "url": "https://ubuntu.com/security/CVE-2025-38183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get() Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8). This seems correct and aligns with the PTP interrupt status register (PTP_INT_STS) specifications. However, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index: lan743x_ptp_io_event_clock_get(..., u8 channel,...) { ... /* Update Local timestamp */ extts = &ptp->extts[channel]; extts->ts.tv_sec = sec; ... } To avoid an out-of-bounds write and utilize all the supported GPIO inputs, set LAN743X_PTP_N_EXTTS to 8. Detected using the static analysis tool - Svace.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38184", "url": "https://ubuntu.com/security/CVE-2025-38184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer , priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0 the ub was in fact a struct dev. when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it. fix this by checking media_id.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38185", "url": "https://ubuntu.com/security/CVE-2025-38185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Free invalid length skb in atmtcp_c_send(). syzbot reported the splat below. [0] vcc_sendmsg() copies data passed from userspace to skb and passes it to vcc->dev->ops->send(). atmtcp_c_send() accesses skb->data as struct atmtcp_hdr after checking if skb->len is 0, but it's not enough. Also, when skb->len == 0, skb and sk (vcc) were leaked because dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing to revert atm_account_tx() in vcc_sendmsg(), which is expected to be done in atm_pop_raw(). Let's properly free skb with an invalid length in atmtcp_c_send(). [0]: BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38324", "url": "https://ubuntu.com/security/CVE-2025-38324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu(). As syzbot reported [0], mpls_route_input_rcu() can be called from mpls_getroute(), where is under RTNL. net->mpls.platform_label is only updated under RTNL. Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to silence the splat. [0]: WARNING: suspicious RCU usage 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ---------------------------- net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961 stack backtrace: CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 ", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38420", "url": "https://ubuntu.com/security/CVE-2025-38420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: do not ping device which has failed to load firmware Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38326", "url": "https://ubuntu.com/security/CVE-2025-38326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: clean device rq_list in aoedev_downdev() An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue().", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38089", "url": "https://ubuntu.com/security/CVE-2025-38089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: handle SVC_GARBAGE during svc auth processing as auth error tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble. The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR. Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash.", "cve_priority": "medium", "cve_public_date": "2025-06-30 08:15:00 UTC" }, { "cve": "CVE-2025-38084", "url": "https://ubuntu.com/security/CVE-2025-38084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 (\"hugetlb: unshare some PMDs when splitting VMAs\"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2]", "cve_priority": "medium", "cve_public_date": "2025-06-28 08:15:00 UTC" }, { "cve": "CVE-2025-38190", "url": "https://ubuntu.com/security/CVE-2025-38190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: Revert atm_account_tx() if copy_from_iter_full() fails. In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by atm_account_tx(). It is expected to be reverted by atm_pop_raw() later called by vcc->dev->ops->send(vcc, skb). However, vcc_sendmsg() misses the same revert when copy_from_iter_full() fails, and then we will leak a socket. Let's factorise the revert part as atm_return_tx() and call it in the failure path. Note that the corresponding sk_wmem_alloc operation can be found in alloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38191", "url": "https://ubuntu.com/security/CVE-2025-38191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference in destroy_previous_session If client set ->PreviousSessionId on kerberos session setup stage, NULL pointer dereference error will happen. Since sess->user is not set yet, It can pass the user argument as NULL to destroy_previous_session. sess->user will be set in ksmbd_krb5_authenticate(). So this patch move calling destroy_previous_session() after ksmbd_krb5_authenticate().", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38192", "url": "https://ubuntu.com/security/CVE-2025-38192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38193", "url": "https://ubuntu.com/security/CVE-2025-38193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: reject invalid perturb period Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch. We want to make sure ctl->perturb_period * HZ will not overflow and is positive. tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38328", "url": "https://ubuntu.com/security/CVE-2025-38328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jffs2: check jffs2_prealloc_raw_node_refs() result in few other places Fuzzing hit another invalid pointer dereference due to the lack of checking whether jffs2_prealloc_raw_node_refs() completed successfully. Subsequent logic implies that the node refs have been allocated. Handle that. The code is ready for propagating the error upwards. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600 Call Trace: jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline] jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497 call_write_iter include/linux/fs.h:2039 [inline] do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740 do_iter_write+0x18c/0x710 fs/read_write.c:866 vfs_writev+0x1db/0x6a0 fs/read_write.c:939 do_pwritev fs/read_write.c:1036 [inline] __do_sys_pwritev fs/read_write.c:1083 [inline] __se_sys_pwritev fs/read_write.c:1078 [inline] __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38194", "url": "https://ubuntu.com/security/CVE-2025-38194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jffs2: check that raw node were preallocated before writing summary Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't check return value of jffs2_prealloc_raw_node_refs and simply lets any error propagate into jffs2_sum_write_data, which eventually calls jffs2_link_node_ref in order to link the summary to an expectedly allocated node. kernel BUG at fs/jffs2/nodelist.c:592! invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592 Call Trace: jffs2_sum_write_data fs/jffs2/summary.c:841 [inline] jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005 call_write_iter include/linux/fs.h:2265 [inline] do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10c/0x170 fs/splice.c:950 splice_direct_to_actor+0x337/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fix this issue by checking return value of jffs2_prealloc_raw_node_refs before calling jffs2_sum_write_data. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38090", "url": "https://ubuntu.com/security/CVE-2025-38090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace.", "cve_priority": "medium", "cve_public_date": "2025-06-30 08:15:00 UTC" }, { "cve": "CVE-2025-38197", "url": "https://ubuntu.com/security/CVE-2025-38197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell_rbu: Fix list usage Pass the correct list head to list_for_each_entry*() when looping through the packet list. Without this patch, reading the packet data via sysfs will show the data incorrectly (because it starts at the wrong packet), and clearing the packet list will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38198", "url": "https://ubuntu.com/security/CVE-2025-38198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Make sure modelist not set on unregistered console It looks like attempting to write to the \"store_modes\" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing \"info\" pointers, so error handling should kick in correctly.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38331", "url": "https://ubuntu.com/security/CVE-2025-38331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Use TOE/TSO on all TCP It is desireable to push the hardware accelerator to also process non-segmented TCP frames: we pass the skb->len to the \"TOE/TSO\" offloader and it will handle them. Without this quirk the driver becomes unstable and lock up and and crash. I do not know exactly why, but it is probably due to the TOE (TCP offload engine) feature that is coupled with the segmentation feature - it is not possible to turn one part off and not the other, either both TOE and TSO are active, or neither of them. Not having the TOE part active seems detrimental, as if that hardware feature is not really supposed to be turned off. The datasheet says: \"Based on packet parsing and TCP connection/NAT table lookup results, the NetEngine puts the packets belonging to the same TCP connection to the same queue for the software to process. The NetEngine puts incoming packets to the buffer or series of buffers for a jumbo packet. With this hardware acceleration, IP/TCP header parsing, checksum validation and connection lookup are offloaded from the software processing.\" After numerous tests with the hardware locking up after something between minutes and hours depending on load using iperf3 I have concluded this is necessary to stabilize the hardware.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38200", "url": "https://ubuntu.com/security/CVE-2025-38200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix MMIO write access to an invalid page in i40e_clear_hw When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38332", "url": "https://ubuntu.com/security/CVE-2025-38332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Use memcpy() for BIOS version The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38342", "url": "https://ubuntu.com/security/CVE-2025-38342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Correct a OOB check in software_node_get_reference_args() software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38334", "url": "https://ubuntu.com/security/CVE-2025-38334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Prevent attempts to reclaim poisoned pages TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode operations including \"EWB\" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a \"TBD\" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply. This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38425", "url": "https://ubuntu.com/security/CVE-2025-38425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: check msg length in SMBUS block read For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38343", "url": "https://ubuntu.com/security/CVE-2025-38343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: drop fragments with multicast or broadcast RA IEEE 802.11 fragmentation can only be applied to unicast frames. Therefore, drop fragments with multicast or broadcast RA. This patch addresses vulnerabilities such as CVE-2020-26145.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38202", "url": "https://ubuntu.com/security/CVE-2025-38202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem() bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38422", "url": "https://ubuntu.com/security/CVE-2025-38422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38344", "url": "https://ubuntu.com/security/CVE-2025-38344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi parse and parseext cache leaks ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5 I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38345", "url": "https://ubuntu.com/security/CVE-2025-38345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi operand cache leak in dswstate.c ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38085", "url": "https://ubuntu.com/security/CVE-2025-38085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.", "cve_priority": "medium", "cve_public_date": "2025-06-28 08:15:00 UTC" }, { "cve": "CVE-2025-38208", "url": "https://ubuntu.com/security/CVE-2025-38208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: add NULL check in automount_fullpath page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38418", "url": "https://ubuntu.com/security/CVE-2025-38418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Release rproc->clean_table after rproc_attach() fails When rproc->state = RPROC_DETACHED is attached to remote processor through rproc_attach(), if rproc_handle_resources() returns failure, then the clean table should be released, otherwise the following memory leak will occur. unreferenced object 0xffff000086a99800 (size 1024): comm \"kworker/u12:3\", pid 59, jiffies 4294893670 (age 121.140s) hex dump (first 32 bytes): 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............ 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............ backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16):", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38419", "url": "https://ubuntu.com/security/CVE-2025-38419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach() When rproc->state = RPROC_DETACHED and rproc_attach() is used to attach to the remote processor, if rproc_handle_resources() returns a failure, the resources allocated by imx_rproc_prepare() should be released, otherwise the following memory leak will occur. Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cleanup() is able to deal with empty lists so it is better to fix the \"goto\" statements in rproc_attach(). replace the \"unprepare_device\" goto statement with \"clean_up_resources\" and get rid of the \"unprepare_device\" label. unreferenced object 0xffff0000861c5d00 (size 128): comm \"kworker/u12:3\", pid 59, jiffies 4294893509 (age 149.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38427", "url": "https://ubuntu.com/security/CVE-2025-38427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: video: screen_info: Relocate framebuffers behind PCI bridges Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory. Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screen_info refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself. Commit 78aa89d1dfba (\"firmware/sysfb: Update screen_info for relocated EFI framebuffers\") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v3: - Only use struct pci_bus_region for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38086", "url": "https://ubuntu.com/security/CVE-2025-38086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ch9200: fix uninitialised access during mii_nway_restart In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called \"buff\", which is initialised with control_read(). However \"buff\" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of \"err == size\" is not met, then \"buff\" remains uninitialised. Once this happens the uninitialised \"buff\" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of \"buff\". To fix this we should check the return value of control_read() and return early on error.", "cve_priority": "medium", "cve_public_date": "2025-06-28 08:15:00 UTC" }, { "cve": "CVE-2025-38346", "url": "https://ubuntu.com/security/CVE-2025-38346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix UAF when lookup kallsym after ftrace disabled The following issue happens with a buggy module: BUG: unable to handle page fault for address: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The above issue may happen as follows: (1) Add kprobe tracepoint; (2) insmod test.ko; (3) Module triggers ftrace disabled; (4) rmmod test.ko; (5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed; ftrace_mod_get_kallsym() ... strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); ... The problem is when a module triggers an issue with ftrace and sets ftrace_disable. The ftrace_disable is set when an anomaly is discovered and to prevent any more damage, ftrace stops all text modification. The issue that happened was that the ftrace_disable stops more than just the text modification. When a module is loaded, its init functions can also be traced. Because kallsyms deletes the init functions after a module has loaded, ftrace saves them when the module is loaded and function tracing is enabled. This allows the output of the function trace to show the init function names instead of just their raw memory addresses. When a module is removed, ftrace_release_mod() is called, and if ftrace_disable is set, it just returns without doing anything more. The problem here is that it leaves the mod_list still around and if kallsyms is called, it will call into this code and access the module memory that has already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); Where the \"mod\" no longer exists and triggers a UAF bug.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38211", "url": "https://ubuntu.com/security/CVE-2025-38211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction The commit 59c68ac31e15 (\"iw_cm: free cm_id resources on the last deref\") simplified cm_id resource management by freeing cm_id once all references to the cm_id were removed. The references are removed either upon completion of iw_cm event handlers or when the application destroys the cm_id. This commit introduced the use-after-free condition where cm_id_private object could still be in use by event handler works during the destruction of cm_id. The commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\") addressed this use-after- free by flushing all pending works at the cm_id destruction. However, still another use-after-free possibility remained. It happens with the work objects allocated for each cm_id_priv within alloc_work_entries() during cm_id creation, and subsequently freed in dealloc_work_entries() once all references to the cm_id are removed. If the cm_id's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver. To avoid the use-after-free of cm_id_private work objects, ensure that the last reference to the cm_id is decremented not in the event handler works, but in the cm_id destruction context. For that purpose, mo ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38212", "url": "https://ubuntu.com/security/CVE-2025-38212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: fix to protect IPCS lookups using RCU syzbot reported that it discovered a use-after-free vulnerability, [0] [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/ idr_for_each() is protected by rwsem, but this is not enough. If it is not protected by RCU read-critical region, when idr_for_each() calls radix_tree_node_free() through call_rcu() to free the radix_tree_node structure, the node will be freed immediately, and when reading the next node in radix_tree_for_each_slot(), the already freed memory may be read. Therefore, we need to add code to make sure that idr_for_each() is protected within the RCU read-critical region when we call it in shm_destroy_orphaned().", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38214", "url": "https://ubuntu.com/security/CVE-2025-38214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38215", "url": "https://ubuntu.com/security/CVE-2025-38215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in do_register_framebuffer() fails to allocate memory for fb_videomode, it will later lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ Even though fbcon_init() checks beforehand if fb_match_mode() in var_to_display() fails, it can not prevent the panic because fbcon_init() does not return error code. Considering this and the comment in the code about fb_match_mode() returning NULL - \"This should not happen\" - it is better to prevent registering the fb_info if its mode was not set successfully. Also move fb_add_videomode() closer to the beginning of do_register_framebuffer() to avoid having to do the cleanup on fail. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38087", "url": "https://ubuntu.com/security/CVE-2025-38087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.", "cve_priority": "medium", "cve_public_date": "2025-06-30 08:15:00 UTC" }, { "cve": "CVE-2025-38416", "url": "https://ubuntu.com/security/CVE-2025-38416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nci: uart: Set tty->disc_data only in success path Setting tty->disc_data before opening the NCI device means we need to clean it up on error paths. This also opens some short window if device starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded (broken hardware?). Close the window by exposing tty->disc_data only on the success path, when opening of the NCI device and try_module_get() succeeds. The code differs in error path in one aspect: tty->disc_data won't be ever assigned thus NULL-ified. This however should not be relevant difference, because of \"tty->disc_data=NULL\" in nci_uart_tty_open().", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38217", "url": "https://ubuntu.com/security/CVE-2025-38217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (ftsteutates) Fix TOCTOU race in fts_read() In the fts_read() function, when handling hwmon_pwm_auto_channels_temp, the code accesses the shared variable data->fan_source[channel] twice without holding any locks. It is first checked against FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again when used as an argument to the BIT() macro. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Another thread executing fts_update_device() can modify the value of data->fan_source[channel] between the check and its use. If the value is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the BIT() macro will be called with a large shift value (BIT(255)). A bit shift by a value greater than or equal to the type width is undefined behavior and can lead to a crash or incorrect values being returned to userspace. Fix this by reading data->fan_source[channel] into a local variable once, eliminating the race condition. Additionally, add a bounds check to ensure the value is less than BITS_PER_LONG before passing it to the BIT() macro, making the code more robust against undefined behavior. This possible bug was found by an experimental static analysis tool developed by our team.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38218", "url": "https://ubuntu.com/security/CVE-2025-38218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sit_bitmap_size w/ below testcase, resize will generate a corrupted image which contains inconsistent metadata, so when mounting such image, it will trigger kernel panic: touch img truncate -s $((512*1024*1024*1024)) img mkfs.f2fs -f img $((256*1024*1024)) resize.f2fs -s -i img -t $((1024*1024*1024)) mount img /mnt/f2fs ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.h:863! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490 Call Trace: f2fs_build_segment_manager+0x11c3/0x2600 f2fs_fill_super+0xe97/0x2840 mount_bdev+0xf4/0x140 legacy_get_tree+0x2b/0x50 vfs_get_tree+0x29/0xd0 path_mount+0x487/0xaf0 __x64_sys_mount+0x116/0x150 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdbfde1bcfe The reaseon is: sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt is 4762, build_sit_entries() -> current_sit_addr() tries to access out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on(). Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38219", "url": "https://ubuntu.com/security/CVE-2025-38219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: prevent kernel warning due to negative i_nlink from corrupted image WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Modules linked in: CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted 6.14.0-12627-g94d471a4f428 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90 <0f> 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6 ff RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005 RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000 R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0 FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0 Call Trace: f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline] f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845 f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909 f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581 vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544 do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608 __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline] __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline] __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652 do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb3d092324b Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0 RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0 R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0 R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001 ", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38347", "url": "https://ubuntu.com/security/CVE-2025-38347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on ino and xnid syzbot reported a f2fs bug as below: INFO: task syz-executor140:5308 blocked for more than 143 seconds. Not tainted 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz-executor140 state:D stack:24016 pid:5308 tgid:5308 ppid:5306 task_flags:0x400140 flags:0x00000006 Call Trace: context_switch kernel/sched/core.c:5378 [inline] __schedule+0x190e/0x4c90 kernel/sched/core.c:6765 __schedule_loop kernel/sched/core.c:6842 [inline] schedule+0x14b/0x320 kernel/sched/core.c:6857 io_schedule+0x8d/0x110 kernel/sched/core.c:7690 folio_wait_bit_common+0x839/0xee0 mm/filemap.c:1317 __folio_lock mm/filemap.c:1664 [inline] folio_lock include/linux/pagemap.h:1163 [inline] __filemap_get_folio+0x147/0xb40 mm/filemap.c:1917 pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87 find_get_page_flags include/linux/pagemap.h:842 [inline] f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776 __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463 read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306 lookup_all_xattrs fs/f2fs/xattr.c:355 [inline] f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533 __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179 f2fs_acl_create fs/f2fs/acl.c:375 [inline] f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418 f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539 f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666 f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765 f2fs_do_add_link+0x28c/0x3a0 fs/f2fs/dir.c:808 f2fs_add_link fs/f2fs/f2fs.h:3616 [inline] f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766 vfs_mknod+0x36d/0x3b0 fs/namei.c:4191 unix_bind_bsd net/unix/af_unix.c:1286 [inline] unix_bind+0x563/0xe30 net/unix/af_unix.c:1379 __sys_bind_socket net/socket.c:1817 [inline] __sys_bind+0x1e4/0x290 net/socket.c:1848 __do_sys_bind net/socket.c:1853 [inline] __se_sys_bind net/socket.c:1851 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1851 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Let's dump and check metadata of corrupted inode, it shows its xattr_nid is the same to its i_ino. dump.f2fs -i 3 chaseyu.img.raw i_xattr_nid [0x 3 : 3] So that, during mknod in the corrupted directory, it tries to get and lock inode page twice, result in deadlock. - f2fs_mknod - f2fs_add_inline_entry - f2fs_get_inode_page --- lock dir's inode page - f2fs_init_acl - f2fs_acl_create(dir,..) - __f2fs_get_acl - f2fs_getxattr - lookup_all_xattrs - __get_node_page --- try to lock dir's inode page In order to fix this, let's add sanity check on ino and xnid.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38428", "url": "https://ubuntu.com/security/CVE-2025-38428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - check record size in ims_pcu_flash_firmware() The \"len\" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the \"len\" is too large it could result in memory corruption when we do \"memcpy(fragment->data, rec->data, len);\"", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38220", "url": "https://ubuntu.com/security/CVE-2025-38220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: only dirty folios when data journaling regular files fstest generic/388 occasionally reproduces a crash that looks as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: ext4_block_zero_page_range+0x30c/0x380 [ext4] ext4_truncate+0x436/0x440 [ext4] ext4_process_orphan+0x5d/0x110 [ext4] ext4_orphan_cleanup+0x124/0x4f0 [ext4] ext4_fill_super+0x262d/0x3110 [ext4] get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x26/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4ed/0x6b0 do_syscall_64+0x82/0x170 ... This occurs when processing a symlink inode from the orphan list. The partial block zeroing code in the truncate path calls ext4_dirty_journalled_data() -> folio_mark_dirty(). The latter calls mapping->a_ops->dirty_folio(), but symlink inodes are not assigned an a_ops vector in ext4, hence the crash. To avoid this problem, update the ext4_dirty_journalled_data() helper to only mark the folio dirty on regular files (for which a_ops is assigned). This also matches the journaling logic in the ext4_symlink() creation path, where ext4_handle_dirty_metadata() is called directly.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38222", "url": "https://ubuntu.com/security/CVE-2025-38222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: inline: fix len overflow in ext4_prepare_inline_data When running the following code on an ext4 filesystem with inline_data feature enabled, it will lead to the bug below. fd = open(\"file1\", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, \"a\", 1, (1UL << 40) + 5UL); That happens because write_begin will succeed as when ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len will be truncated, leading to ext4_prepare_inline_data parameter to be 6 instead of 0x10000000006. Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); at ext4_write_inline_data. Fix it by using a loff_t type for the len parameter in ext4_prepare_inline_data instead of an unsigned int. [ 44.545164] ------------[ cut here ]------------ [ 44.545530] kernel BUG at fs/ext4/inline.c:240! [ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb [ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100 [ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49 [ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216 [ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006 [ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738 [ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000 [ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738 [ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000 [ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0 [ 44.546523] PKRU: 55555554 [ 44.546523] Call Trace: [ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0 [ 44.546523] generic_perform_write+0x17e/0x270 [ 44.546523] ext4_buffered_write_iter+0xc8/0x170 [ 44.546523] vfs_write+0x2be/0x3e0 [ 44.546523] __x64_sys_pwrite64+0x6d/0xc0 [ 44.546523] do_syscall_64+0x6a/0xf0 [ 44.546523] ? __wake_up+0x89/0xb0 [ 44.546523] ? xas_find+0x72/0x1c0 [ 44.546523] ? next_uptodate_folio+0x317/0x330 [ 44.546523] ? set_pte_range+0x1a6/0x270 [ 44.546523] ? filemap_map_pages+0x6ee/0x840 [ 44.546523] ? ext4_setattr+0x2fa/0x750 [ 44.546523] ? do_pte_missing+0x128/0xf70 [ 44.546523] ? security_inode_post_setattr+0x3e/0xd0 [ 44.546523] ? ___pte_offset_map+0x19/0x100 [ 44.546523] ? handle_mm_fault+0x721/0xa10 [ 44.546523] ? do_user_addr_fault+0x197/0x730 [ 44.546523] ? do_syscall_64+0x76/0xf0 [ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60 [ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90 [ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 44.546523] RIP: 0033:0x7f42999c6687 [ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff [ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012 [ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687 [ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003 [ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000 [ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38336", "url": "https://ubuntu.com/security/CVE-2025-38336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330 The controller has a hardware bug that can hard hang the system when doing ATAPI DMAs without any trace of what happened. Depending on the device attached, it can also prevent the system from booting. In this case, the system hangs when reading the ATIP from optical media with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, running at UDMA/33. The issue can be reproduced by running the same command with a cygwin build of cdrecord on WinXP, although it requires more attempts to cause it. The hang in that case is also resolved by forcing PIO. It doesn't appear that VIA has produced any drivers for that OS, thus no known workaround exists. HDDs attached to the controller do not suffer from any DMA issues.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38429", "url": "https://ubuntu.com/security/CVE-2025-38429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Update read pointer only after buffer is written Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated before the buffer is written, potentially causing race conditions where the host sees an updated read pointer before the buffer is actually written. Updating rd_offset prematurely can lead to the host accessing an uninitialized or incomplete element, resulting in data corruption. Invoke the buffer write before updating rd_offset to ensure the element is fully written before signaling its availability.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38225", "url": "https://ubuntu.com/security/CVE-2025-38225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Cleanup after an allocation error When allocation failures are not cleaned up by the driver, further allocation errors will be false-positives, which will cause buffers to remain uninitialized and cause NULL pointer dereferences. Ensure proper cleanup of failed allocations to prevent these issues.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38226", "url": "https://ubuntu.com/security/CVE-2025-38226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: Change the siize of the composing syzkaller found a bug: BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304 CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline] vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629 vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The composition size cannot be larger than the size of fmt_cap_rect. So execute v4l2_rect_map_inside() even if has_compose_cap == 0.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38229", "url": "https://ubuntu.com/security/CVE-2025-38229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cxusb: no longer judge rbuf when the write fails syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38337", "url": "https://ubuntu.com/security/CVE-2025-38337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() Since handle->h_transaction may be a NULL pointer, so we should change it to call is_handle_aborted(handle) first before dereferencing it. And the following data-race was reported in my fuzzer: ================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ================================================================== This issue is caused by missing data-race annotation for jh->b_modified. Therefore, the missing annotation needs to be added.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38338", "url": "https://ubuntu.com/security/CVE-2025-38338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which never happens because nobody is really holding the folio lock.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38231", "url": "https://ubuntu.com/security/CVE-2025-38231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Initialize ssc before laundromat_work to prevent NULL dereference In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through nfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized, this can cause NULL pointer dereference. Normally the delayed start of laundromat_work allows sufficient time for nfsd_ssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4_state_start_net -> nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done -> cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), the delayed work may start before nfsd_ssc initialization finishes. Fix this by moving nfsd_ssc initialization before starting laundromat_work.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38430", "url": "https://ubuntu.com/security/CVE-2025-38430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request If the request being processed is not a v4 compound request, then examining the cstate can have undefined results. This patch adds a check that the rpc procedure being executed (rq_procinfo) is the NFSPROC4_COMPOUND procedure.", "cve_priority": "medium", "cve_public_date": "2025-07-25 15:15:00 UTC" }, { "cve": "CVE-2025-38348", "url": "https://ubuntu.com/security/CVE-2025-38348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback() Robert Morris reported: |If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun. This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the \"firmware\" altered the value and no longer copies them. The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.", "cve_priority": "medium", "cve_public_date": "2025-07-10 09:15:00 UTC" }, { "cve": "CVE-2025-38101", "url": "https://ubuntu.com/security/CVE-2025-38101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set() Enlarge the critical section in ring_buffer_subbuf_order_set() to ensure that error handling takes place with per-buffer mutex held, thus preventing list corruption and other concurrency-related issues.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38269", "url": "https://ubuntu.com/security/CVE-2025-38269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: exit after state insertion failure at btrfs_convert_extent_bit() If insert_state() state failed it returns an error pointer and we call extent_io_tree_panic() which will trigger a BUG() call. However if CONFIG_BUG is disabled, which is an uncommon and exotic scenario, then we fallthrough and call cache_state() which will dereference the error pointer, resulting in an invalid memory access. So jump to the 'out' label after calling extent_io_tree_panic(), it also makes the code more clear besides dealing with the exotic scenario where CONFIG_BUG is disabled.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38303", "url": "https://ubuntu.com/security/CVE-2025-38303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38414", "url": "https://ubuntu.com/security/CVE-2025-38414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850 GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms. Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38125", "url": "https://ubuntu.com/security/CVE-2025-38125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38129", "url": "https://ubuntu.com/security/CVE-2025-38129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: page_pool: Fix use-after-free in page_pool_recycle_in_ring syzbot reported a uaf in page_pool_recycle_in_ring: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943 CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline] root cause is: page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool \t\t\t\tpage_pool_release \t\t\t\t page_pool_scrub \t\t\t\t page_pool_empty_ring \t\t\t\t ptr_ring_consume \t\t\t\t page_pool_return_page //release all page \t\t\t\t __page_pool_destroy \t\t\t\t free_percpu(pool->recycle_stats); \t\t\t\t free(pool) //free spin_unlock(&r->producer_lock); //pool->ring uaf read recycle_stat_inc(pool, ring); page_pool can be free while page pool recycle the last page in ring. Add producer-lock barrier to page_pool_release to prevent the page pool from being free before all pages have been recycled. recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38156", "url": "https://ubuntu.com/security/CVE-2025-38156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init()", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38162", "url": "https://ubuntu.com/security/CVE-2025-38162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: prevent overflow in lookup table allocation When calculating the lookup table size, ensure the following multiplication does not overflow: - desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case. - NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field. Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this. While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38292", "url": "https://ubuntu.com/security/CVE-2025-38292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix invalid access to memory In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean is_continuation is part of rxcb. Currently, after freeing the skb, the rxcb->is_continuation accessed again which is wrong since the memory is already freed. This might lead use-after-free error. Hence, fix by locally defining bool is_continuation from rxcb, so that after freeing skb, is_continuation can be used. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38164", "url": "https://ubuntu.com/security/CVE-2025-38164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: zone: fix to avoid inconsistence in between SIT and SSA w/ below testcase, it will cause inconsistence in between SIT and SSA. create_null_blk 512 2 1024 1024 mkfs.f2fs -m /dev/nullb0 mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/file f2fs_io pinfile set /mnt/f2fs/file fallocate -l 4GiB /mnt/f2fs/file F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G O 6.13.0-rc1 #84 Tainted: [O]=OOT_MODULE Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: dump_stack_lvl+0xb3/0xd0 dump_stack+0x14/0x20 f2fs_handle_critical_error+0x18c/0x220 [f2fs] f2fs_stop_checkpoint+0x38/0x50 [f2fs] do_garbage_collect+0x674/0x6e0 [f2fs] f2fs_gc_range+0x12b/0x230 [f2fs] f2fs_allocate_pinning_section+0x5c/0x150 [f2fs] f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs] f2fs_fallocate+0x3c3/0x410 [f2fs] vfs_fallocate+0x15f/0x4b0 __x64_sys_fallocate+0x4a/0x80 x64_sys_call+0x15e8/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f9dba5197ca F2FS-fs (nullb0): Stopped filesystem due to reason: 4 The reason is f2fs_gc_range() may try to migrate block in curseg, however, its SSA block is not uptodate due to the last summary block data is still in cache of curseg. In this patch, we add a condition in f2fs_gc_range() to check whether section is opened or not, and skip block migration for opened section.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38169", "url": "https://ubuntu.com/security/CVE-2025-38169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP On system with SME, a thread's kernel FPSIMD state may be erroneously clobbered during a context switch immediately after that state is restored. Systems without SME are unaffected. If the CPU happens to be in streaming SVE mode before a context switch to a thread with kernel FPSIMD state, fpsimd_thread_switch() will restore the kernel FPSIMD state using fpsimd_load_kernel_state() while the CPU is still in streaming SVE mode. When fpsimd_thread_switch() subsequently calls fpsimd_flush_cpu_state(), this will execute an SMSTOP, causing an exit from streaming SVE mode. The exit from streaming SVE mode will cause the hardware to reset a number of FPSIMD/SVE/SME registers, clobbering the FPSIMD state. Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel FPSIMD state.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38299", "url": "https://ubuntu.com/security/CVE-2025-38299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY() ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(), in the case the codec dai_name will be null. Avoid a crash if the device tree is not assigning a codec to these links. [ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but active_mm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: events_unbound deferred_probe_work_func [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : __pi_strcmp+0x24/0x140 [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8 [ 1.203644] platform_probe+0x70/0xe8 [ 1.204106] really_probe+0xc8/0x3a0 [ 1.204556] __driver_probe_device+0x84/0x160 [ 1.205104] driver_probe_device+0x44/0x130 [ 1.205630] __device_attach_driver+0xc4/0x170 [ 1.206189] bus_for_each_drv+0x8c/0xf8 [ 1.206672] __device_attach+0xa8/0x1c8 [ 1.207155] device_initial_probe+0x1c/0x30 [ 1.207681] bus_probe_device+0xb0/0xc0 [ 1.208165] deferred_probe_work_func+0xa4/0x100 [ 1.208747] process_one_work+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38100", "url": "https://ubuntu.com/security/CVE-2025-38100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38102", "url": "https://ubuntu.com/security/CVE-2025-38102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify During our test, it is found that a warning can be trigger in try_grab_folio as follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]--- Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow: cpu0\t\t\tcpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page \t\t\tvmci_host_do_set_notify \t\t\tvmci_ctx_unset_notify \t\t\tnotify_page = context->notify_page; \t\t\tif (notify_page) \t\t\tput_page(notify_page);\t// page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38103", "url": "https://ubuntu.com/security/CVE-2025-38103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38107", "url": "https://ubuntu.com/security/CVE-2025-38107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: fix a race in ets_qdisc_change() Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38108", "url": "https://ubuntu.com/security/CVE-2025-38108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: red: fix a race in __red_change() Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38109", "url": "https://ubuntu.com/security/CVE-2025-38109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix ECVF vports unload on shutdown flow Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed. ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports. kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220 ---------------- [] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]---", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38304", "url": "https://ubuntu.com/security/CVE-2025-38304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38110", "url": "https://ubuntu.com/security/CVE-2025-38110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds clause 45 read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38111", "url": "https://ubuntu.com/security/CVE-2025-38111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38112", "url": "https://ubuntu.com/security/CVE-2025-38112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix TOCTOU issue in sk_is_readable() sk->sk_prot->sock_is_readable is a valid function pointer when sk resides in a sockmap. After the last sk_psock_put() (which usually happens when socket is removed from sockmap), sk->sk_prot gets restored and sk->sk_prot->sock_is_readable becomes NULL. This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded after the initial check. Which in turn may lead to a null pointer dereference. Ensure the function pointer does not turn NULL after the check.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38113", "url": "https://ubuntu.com/security/CVE-2025-38113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Fix NULL pointer dereference when nosmp is used With nosmp in cmdline, other CPUs are not brought up, leaving their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu() dereferences these NULL pointers, causing panic. Panic backtrace: [ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8 ... [ 0.403255] [] cppc_allow_fast_switch+0x6a/0xd4 ... Kernel panic - not syncing: Attempted to kill init! [ rjw: New subject ]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38088", "url": "https://ubuntu.com/security/CVE-2025-38088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size.", "cve_priority": "medium", "cve_public_date": "2025-06-30 08:15:00 UTC" }, { "cve": "CVE-2025-38115", "url": "https://ubuntu.com/security/CVE-2025-38115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: fix a potential crash on gso_skb handling SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 &", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38305", "url": "https://ubuntu.com/security/CVE-2025-38305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38117", "url": "https://ubuntu.com/security/CVE-2025-38117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Protect mgmt_pending list with its own lock This uses a mutex to protect from concurrent access of mgmt_pending list which can cause crashes like: ================================================================== BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318 CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38119", "url": "https://ubuntu.com/security/CVE-2025-38119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before. Backtrace: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 [ bvanassche: rewrote patch description ]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38307", "url": "https://ubuntu.com/security/CVE-2025-38307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Verify content returned by parse_int_array() The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38310", "url": "https://ubuntu.com/security/CVE-2025-38310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38120", "url": "https://ubuntu.com/security/CVE-2025-38120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo_avx2: fix initial map fill If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map. The early fix was incomplete and did only fix up the generic C implementation. A followup patch adds a test case to nft_concat_range.sh.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38122", "url": "https://ubuntu.com/security/CVE-2025-38122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo() did not check for this case before dereferencing the returned pointer. Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails. This improves robustness in low-memory scenarios.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38123", "url": "https://ubuntu.com/security/CVE-2025-38123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: Fix napi rx poll issue When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic. BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:dev_gro_receive+0x3a/0x620 [...] Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)] ? dev_gro_receive+0x3a/0x620 napi_gro_receive+0xad/0x170 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)] t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)] net_rx_action+0x103/0x470 irq_exit_rcu+0x13a/0x310 sysvec_apic_timer_interrupt+0x56/0x90 ", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38124", "url": "https://ubuntu.com/security/CVE-2025-38124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix udp gso skb_segment after pull from frag_list Commit a1e40ac5b5e9 (\"net: gso: fix udp gso fraglist segmentation after pull from frag_list\") detected invalid geometry in frag_list skbs and redirects them from skb_segment_list to more robust skb_segment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skb_segment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust. If only part of the fraglist payload is pulled into head_skb, it will always cause exception when splitting skbs by skb_segment. For detailed call stack information, see below. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify fraglist skbs, breaking these invariants. In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes. The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because payload was pulled into head_skb, it needs to be linearized before pass to regular skb_segment. skb_segment+0xcd0/0xd14 __udp_gso_segment+0x334/0x5f4 udp4_ufo_fragment+0x118/0x15c inet_gso_segment+0x164/0x338 skb_mac_gso_segment+0xc4/0x13c __skb_gso_segment+0xc4/0x124 validate_xmit_skb+0x9c/0x2c0 validate_xmit_skb_list+0x4c/0x80 sch_direct_xmit+0x70/0x404 __dev_queue_xmit+0x64c/0xe5c neigh_resolve_output+0x178/0x1c4 ip_finish_output2+0x37c/0x47c __ip_finish_output+0x194/0x240 ip_finish_output+0x20/0xf4 ip_output+0x100/0x1a0 NF_HOOK+0xc4/0x16c ip_forward+0x314/0x32c ip_rcv+0x90/0x118 __netif_receive_skb+0x74/0x124 process_backlog+0xe8/0x1a4 __napi_poll+0x5c/0x1f8 net_rx_action+0x154/0x314 handle_softirqs+0x154/0x4b8 [118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000 [118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14 [118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14 [118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38126", "url": "https://ubuntu.com/security/CVE-2025-38126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping The stmmac platform drivers that do not open-code the clk_ptp_rate value after having retrieved the default one from the device-tree can end up with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8) Prevent this division by 0 by adding an explicit check and error log about the actual issue. While at it, remove the same check from stmmac_ptp_register, which then becomes duplicate", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38127", "url": "https://ubuntu.com/security/CVE-2025-38127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix Tx scheduler error handling in XDP callback When the XDP program is loaded, the XDP callback adds new Tx queues. This means that the callback must update the Tx scheduler with the new queue number. In the event of a Tx scheduler failure, the XDP callback should also fail and roll back any changes previously made for XDP preparation. The previous implementation had a bug that not all changes made by the XDP callback were rolled back. This caused the crash with the following call trace: [ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5 [ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI [ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary) [ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022 [ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice] [...] [ +0.002715] Call Trace: [ +0.002452] [ +0.002021] ? __die_body.cold+0x19/0x29 [ +0.003922] ? die_addr+0x3c/0x60 [ +0.003319] ? exc_general_protection+0x17c/0x400 [ +0.004707] ? asm_exc_general_protection+0x26/0x30 [ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice] [ +0.004835] ice_napi_poll+0x665/0x680 [ice] [ +0.004320] __napi_poll+0x28/0x190 [ +0.003500] net_rx_action+0x198/0x360 [ +0.003752] ? update_rq_clock+0x39/0x220 [ +0.004013] handle_softirqs+0xf1/0x340 [ +0.003840] ? sched_clock_cpu+0xf/0x1f0 [ +0.003925] __irq_exit_rcu+0xc2/0xe0 [ +0.003665] common_interrupt+0x85/0xa0 [ +0.003839] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40 [ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690 Fix this by performing the missing unmapping of XDP queues from q_vectors and setting the XDP rings pointer back to NULL after all those queues are released. Also, add an immediate exit from the XDP callback in case of ring preparation failure.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38131", "url": "https://ubuntu.com/security/CVE-2025-38131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: prevent deactivate active config while enabling the config While enable active config via cscfg_csdev_enable_active_config(), active config could be deactivated via configfs' sysfs interface. This could make UAF issue in below scenario: CPU0 CPU1 (sysfs enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() unload module // access to config_desc which freed // while unloading module. cscfg_csdev_enable_config To address this, use cscfg_config_desc's active_cnt as a reference count which will be holded when - activate the config. - enable the activated config. and put the module reference when config_active_cnt == 0.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38274", "url": "https://ubuntu.com/security/CVE-2025-38274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: fix potential null pointer deref in fpga_mgr_test_img_load_sgt() fpga_mgr_test_img_load_sgt() allocates memory for sgt using kunit_kzalloc() however it does not check if the allocation failed. It then passes sgt to sg_alloc_table(), which passes it to __sg_alloc_table(). This function calls memset() on sgt in an attempt to zero it out. If the allocation fails then sgt will be NULL and the memset will trigger a NULL pointer dereference. Fix this by checking the allocation with KUNIT_ASSERT_NOT_ERR_OR_NULL().", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38135", "url": "https://ubuntu.com/security/CVE-2025-38135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: Fix potential null-ptr-deref in mlb_usio_probe() devm_ioremap() can return NULL on error. Currently, mlb_usio_probe() does not check for this case, which could result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38136", "url": "https://ubuntu.com/security/CVE-2025-38136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Reorder clock handling and power management in probe Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access before enabling clocks Since `iowrite16()` is performed without ensuring the required clocks are enabled, this can lead to access errors. To fix this, enable PM runtime early in the probe function and ensure clocks are acquired before register access, preventing crashes like the following on RZ/V2H: [13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP [13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750 [13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Call trace: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38138", "url": "https://ubuntu.com/security/CVE-2025-38138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Add NULL check in udma_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, udma_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38275", "url": "https://ubuntu.com/security/CVE-2025-38275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38142", "url": "https://ubuntu.com/security/CVE-2025-38142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (asus-ec-sensors) check sensor index in read_string() Prevent a potential invalid memory access when the requested sensor is not found. find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info(). Add a proper check to return -EINVAL if sensor_index is negative. Found by Linux Verification Center (linuxtesting.org) with SVACE. [groeck: Return error code returned from find_ec_sensor_index]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38277", "url": "https://ubuntu.com/security/CVE-2025-38277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: nand: ecc-mxic: Fix use of uninitialized variable ret If ctx->steps is zero, the loop processing ECC steps is skipped, and the variable ret remains uninitialized. It is later checked and returned, which leads to undefined behavior and may cause unpredictable results in user space or kernel crashes. This scenario can be triggered in edge cases such as misconfigured geometry, ECC engine misuse, or if ctx->steps is not validated after initialization. Initialize ret to zero before the loop to ensure correct and safe behavior regardless of the ctx->steps value. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38143", "url": "https://ubuntu.com/security/CVE-2025-38143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: pm8941: Add NULL check in wled_configure() devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38312", "url": "https://ubuntu.com/security/CVE-2025-38312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38145", "url": "https://ubuntu.com/security/CVE-2025-38145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop() devm_kasprintf() returns NULL when memory allocation fails. Currently, aspeed_lpc_enable_snoop() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. [arj: Fix Fixes: tag to use subject from 3772e5da4454]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38313", "url": "https://ubuntu.com/security/CVE-2025-38313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix double-free on mc_dev The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is a false-positive. WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38415", "url": "https://ubuntu.com/security/CVE-2025-38415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check return result of sb_min_blocksize Syzkaller reports an \"UBSAN: shift-out-of-bounds in squashfs_bio_read\" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl(\"/dev/loop0\", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize().", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2025-38146", "url": "https://ubuntu.com/security/CVE-2025-38146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix the dead loop of MPLS parse The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally. stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type '__be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0 ", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38147", "url": "https://ubuntu.com/security/CVE-2025-38147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: calipso: Don't call calipso functions for AF_INET sk. syzkaller reported a null-ptr-deref in txopt_get(). [0] The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo, so struct ipv6_pinfo was NULL there. However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6 is always set in inet6_create(), meaning the socket was not IPv6 one. The root cause is missing validation in netlbl_conn_setattr(). netlbl_conn_setattr() switches branches based on struct sockaddr.sa_family, which is passed from userspace. However, netlbl_conn_setattr() does not check if the address family matches the socket. The syzkaller must have called connect() for an IPv6 address on an IPv4 socket. We have a proper validation in tcp_v[46]_connect(), but security_socket_connect() is called in the earlier stage. Let's copy the validation to netlbl_conn_setattr(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:txopt_get include/net/ipv6.h:390 [inline] RIP: 0010: Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00 RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070 RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00 R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80 FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f901b61a12d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003 RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in:", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38278", "url": "https://ubuntu.com/security/CVE-2025-38278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: QOS: Refactor TC_HTB_LEAF_DEL_LAST callback This patch addresses below issues, 1. Active traffic on the leaf node must be stopped before its send queue is reassigned to the parent. This patch resolves the issue by marking the node as 'Inner'. 2. During a system reboot, the interface receives TC_HTB_LEAF_DEL and TC_HTB_LEAF_DEL_LAST callbacks to delete its HTB queues. In the case of TC_HTB_LEAF_DEL_LAST, although the same send queue is reassigned to the parent, the current logic still attempts to update the real number of queues, leadning to below warnings New queues can't be registered after device unregistration. WARNING: CPU: 0 PID: 6475 at net/core/net-sysfs.c:1714 netdev_queue_update_kobjects+0x1e4/0x200", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38148", "url": "https://ubuntu.com/security/CVE-2025-38148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: mscc: Fix memory leak when using one step timestamping Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38149", "url": "https://ubuntu.com/security/CVE-2025-38149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clear phydev->devlink when the link is deleted There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the \"error\" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows. [ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is deleted.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38280", "url": "https://ubuntu.com/security/CVE-2025-38280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid __bpf_prog_ret0_warn when jit fails syzkaller reported an issue: WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Modules linked in: CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ... When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable. This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog, but jit failed due to FAULT_INJECTION. As a result, incorrectly treats the program as valid, when the program runs it calls `__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38153", "url": "https://ubuntu.com/security/CVE-2025-38153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: fix error handling of usbnet read calls Syzkaller, courtesy of syzbot, identified an error (see report [1]) in aqc111 driver, caused by incomplete sanitation of usb read calls' results. This problem is quite similar to the one fixed in commit 920a9fa27e78 (\"net: asix: add proper error handling of usb read errors\"). For instance, usbnet_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will not check its result properly. As [1] shows, this may lead to MAC address in aqc111_bind() being only partly initialized, triggering KMSAN warnings. Fix the issue by verifying that the number of bytes read is as expected and not less. [1] Partial syzbot report: BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38154", "url": "https://ubuntu.com/security/CVE-2025-38154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Avoid using sk_socket after free when sending The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected. Race conditions: ''' CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here ''' The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } ''' Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions. With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work. If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync(). In summary, we require synchronization to coordinate the backlog thread and close() thread. The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38155", "url": "https://ubuntu.com/security/CVE-2025-38155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init().", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38282", "url": "https://ubuntu.com/security/CVE-2025-38282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernfs: Relax constraint in draining guard The active reference lifecycle provides the break/unbreak mechanism but the active reference is not truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of kn->active counting. Assuming this mechanism is in place, the WARN check in kernfs_should_drain_open_files() is too sensitive -- it may transiently catch those (rightful) callers between kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen Ridong: \tkernfs_remove_by_name_ns\tkernfs_get_active // active=1 \t__kernfs_remove\t\t\t\t\t // active=0x80000002 \tkernfs_drain\t\t\t... \twait_event \t//waiting (active == 0x80000001) \t\t\t\t\tkernfs_break_active_protection \t\t\t\t\t// active = 0x80000001 \t// continue \t\t\t\t\tkernfs_unbreak_active_protection \t\t\t\t\t// active = 0x80000002 \t... \tkernfs_should_drain_open_files \t// warning occurs \t\t\t\t\tkernfs_put_active To avoid the false positives (mind panic_on_warn) remove the check altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with larger rework.)", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38157", "url": "https://ubuntu.com/security/CVE-2025-38157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Abort software beacon handling if disabled A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38283", "url": "https://ubuntu.com/security/CVE-2025-38283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: bugfix live migration function without VF device driver If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors. Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38158", "url": "https://ubuntu.com/security/CVE-2025-38158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: fix XQE dma address error The dma addresses of EQE and AEQE are wrong after migration and results in guest kernel-mode encryption services failure. Comparing the definition of hardware registers, we found that there was an error when the data read from the register was combined into an address. Therefore, the address combination sequence needs to be corrected. Even after fixing the above problem, we still have an issue where the Guest from an old kernel can get migrated to new kernel and may result in wrong data. In order to ensure that the address is correct after migration, if an old magic number is detected, the dma address needs to be updated.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-39890", "url": "https://ubuntu.com/security/CVE-2025-39890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event Currently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_caps is not freed in the failure case, causing a memory leak. The following trace is observed in kmemleak: unreferenced object 0xffff8b3eb5789c00 (size 1024): comm \"softirq\", pid 0, jiffies 4294942577 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{... 01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8.. backtrace (crc 44e1c357): __kmalloc_noprof+0x30b/0x410 ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k] ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k] ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k] ath12k_ce_recv_process_cb+0x218/0x300 [ath12k] ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k] process_one_work+0x219/0x680 bh_worker+0x198/0x1f0 tasklet_action+0x13/0x30 handle_softirqs+0xca/0x460 __irq_exit_rcu+0xbe/0x110 irq_exit_rcu+0x9/0x30 Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-09-24 11:15:00 UTC" }, { "cve": "CVE-2025-38159", "url": "https://ubuntu.com/security/CVE-2025-38159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38285", "url": "https://ubuntu.com/security/CVE-2025-38285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix WARN() in get_bpf_raw_tp_regs syzkaller reported an issue: WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38286", "url": "https://ubuntu.com/security/CVE-2025-38286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91: Fix possible out-of-boundary access at91_gpio_probe() doesn't check that given OF alias is not available or something went wrong when trying to get it. This might have consequences when accessing gpio_chips array with that value as an index. Note, that BUG() can be compiled out and hence won't actually perform the required checks.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38160", "url": "https://ubuntu.com/security/CVE-2025-38160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Add NULL check in raspberrypi_clk_register() devm_kasprintf() returns NULL when memory allocation fails. Currently, raspberrypi_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38161", "url": "https://ubuntu.com/security/CVE-2025-38161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure. Now properly rollback the object to its original state upon such failure. In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38290", "url": "https://ubuntu.com/security/CVE-2025-38290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath12k_core_halt() only reinitializes the \"arvifs\" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head \"arvifs\", but the next of the list head \"arvifs\" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head \"arvifs\" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute normally. Call trace: __list_del_entry_valid_or_report+0xd4/0x100 (P) ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k] ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k] cfg80211_wiphy_work+0xfc/0x100 process_one_work+0x164/0x2d0 worker_thread+0x254/0x380 kthread+0xfc/0x100 ret_from_fork+0x10/0x20 The change is mostly copied from the ath11k patch: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38163", "url": "https://ubuntu.com/security/CVE-2025-38163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sbi->total_valid_block_count syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94 The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38165", "url": "https://ubuntu.com/security/CVE-2025-38165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix panic when calling skb_linearize The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000 Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events sk_psock_backlog ... [ 657.469610] [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? do_trap+0x1d0/0x270 [ 657.470118] ? pskb_expand_head+0x612/0xf40 [ 657.470376] ? pskb_expand_head+0x612/0xf40 [ 657.470620] ? do_error_trap+0xa3/0x170 [ 657.470846] ? pskb_expand_head+0x612/0xf40 [ 657.471092] ? handle_invalid_op+0x2c/0x40 [ 657.471335] ? pskb_expand_head+0x612/0xf40 [ 657.471579] ? exc_invalid_op+0x2d/0x40 [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20 [ 657.472052] ? pskb_expand_head+0xd1/0xf40 [ 657.472292] ? pskb_expand_head+0x612/0xf40 [ 657.472540] ? lock_acquire+0x18f/0x4e0 [ 657.472766] ? find_held_lock+0x2d/0x110 [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10 [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470 [ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10 [ 657.473826] __pskb_pull_tail+0xfd/0x1d20 [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90 [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510 [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0 [ 657.476010] sk_psock_backlog+0x5cf/0xd70 [ 657.476637] process_one_work+0x858/0x1a20 ''' The panic originates from the assertion BUG_ON(skb_shared(skb)) in skb_linearize(). A previous commit(see Fixes tag) introduced skb_get() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed. The \"--rx-strp 100000\" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize. To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue. ''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress____________ ↓ | | → sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply_________________↑ skb_linearize ''' Note that for verdict_apply path, the skb_get operation is unnecessary so we add 'take_ref' param to control it's behavior.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38166", "url": "https://ubuntu.com/security/CVE-2025-38166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix ktls panic with sockmap [ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ...... After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data(). If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); ''' The changes in this commit are based on the following considerations: 1. When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic. 2. We can not calculate the correct number of bytes to revert msg_iter. Assume the original data is \"abcdefgh\" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: \"abc?de?fgh?\". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes \"?fgh?\" will be cached until the length meets the cork_bytes requirement. However, some data in \"?fgh?\" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data \"?\" we pushed. So it doesn't seem as simple as just reverting through an offset of msg_iter. 3. For non-TLS sockets in tcp_bpf_sendmsg, when a \"cork\" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached. Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { \tif (ret == -ENOSPC) \t\tret = 0; \tgoto send_end; ''' So it's ok to just return 'copied' without error when a \"cork\" situation occurs.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38293", "url": "https://ubuntu.com/security/CVE-2025-38293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the \"arvifs\" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head \"arvifs\", but the next of the list head \"arvifs\" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head \"arvifs\" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally. Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38295", "url": "https://ubuntu.com/security/CVE-2025-38295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create() The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses smp_processor_id(), which assumes disabled preemption. This leads to kernel warnings during module loading because meson_ddr_pmu_create() can be called in a preemptible context. Following kernel warning and stack trace: [ 31.745138] [ T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289 [ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38 [ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0 [ 31.745181] [ T2289] Tainted: [W]=WARN [ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT) [ 31.745188] [ T2289] Call trace: [ 31.745191] [ T2289] show_stack+0x28/0x40 (C) [ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198 [ 31.745205] [ T2289] dump_stack+0x20/0x50 [ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0 [ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38 [ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745246] [ T2289] platform_probe+0x98/0xe0 [ 31.745254] [ T2289] really_probe+0x144/0x3f8 [ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180 [ 31.745261] [ T2289] driver_probe_device+0x54/0x268 [ 31.745264] [ T2289] __driver_attach+0x11c/0x288 [ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160 [ 31.745274] [ T2289] driver_attach+0x34/0x50 [ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0 [ 31.745281] [ T2289] driver_register+0x78/0x120 [ 31.745285] [ T2289] __platform_driver_register+0x30/0x48 [ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745298] [ T2289] do_one_initcall+0x11c/0x438 [ 31.745303] [ T2289] do_init_module+0x68/0x228 [ 31.745311] [ T2289] load_module+0x118c/0x13a8 [ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390 [ 31.745320] [ T2289] invoke_syscall+0x74/0x108 [ 31.745326] [ T2289] el0_svc_common+0x90/0xf8 [ 31.745330] [ T2289] do_el0_svc+0x2c/0x48 [ 31.745333] [ T2289] el0_svc+0x60/0x150 [ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118 [ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0 Changes replaces smp_processor_id() with raw_smp_processor_id() to ensure safe CPU ID retrieval in preemptible contexts.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38167", "url": "https://ubuntu.com/security/CVE-2025-38167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: handle hdr_first_de() return value The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently. Additionally, error handling for the return value already exists at other points where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38170", "url": "https://ubuntu.com/security/CVE-2025-38170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Discard stale CPU state when handling SME traps The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad (\"arm64/sve: Discard stale CPU state when handling SVE traps\") The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g. | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Note: this was originallly posted as [1]. [ Rutland: rewrite commit message ]", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38319", "url": "https://ubuntu.com/security/CVE-2025-38319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38298", "url": "https://ubuntu.com/security/CVE-2025-38298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/skx_common: Fix general protection fault After loading i10nm_edac (which automatically loads skx_edac_common), if unload only i10nm_edac, then reload it and perform error injection testing, a general protection fault may occur: mce: [Hardware Error]: Machine check events logged Oops: general protection fault ... ... Workqueue: events mce_gen_pool_process RIP: 0010:string+0x53/0xe0 ... Call Trace: ? die_addr+0x37/0x90 ? exc_general_protection+0x1e7/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? string+0x53/0xe0 vsnprintf+0x23e/0x4c0 snprintf+0x4d/0x70 skx_adxl_decode+0x16a/0x330 [skx_edac_common] skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common] skx_mce_check_error+0x17/0x20 [skx_edac_common] ... The issue arose was because the variable 'adxl_component_count' (inside skx_edac_common), which counts the ADXL components, was not reset. During the reloading of i10nm_edac, the count was incremented by the actual number of ADXL components again, resulting in a count that was double the real number of ADXL components. This led to an out-of-bounds reference to the ADXL component array, causing the general protection fault above. Fix this issue by resetting the 'adxl_component_count' in adxl_put(), which is called during the unloading of {skx,i10nm}_edac.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38173", "url": "https://ubuntu.com/security/CVE-2025-38173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/cesa - Handle zero-length skcipher requests Do not access random memory for zero-length skcipher requests. Just return 0.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38300", "url": "https://ubuntu.com/security/CVE-2025-38300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare() Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare(): 1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the \"theend_sgs\" error path, call dma unmap only if the corresponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the \"theend_iv\" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- To fix this, check for !dma_mapping_error() before calling dma_unmap_single() on the \"theend_iv\" path.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38174", "url": "https://ubuntu.com/security/CVE-2025-38174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Do not double dequeue a configuration request Some of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30 The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be scheduled twice for a request: first time via frame.callback from ring_work() and second time from tb_cfg_request(). Both times kworkers will execute tb_cfg_request_dequeue(), which results in double list_del() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122). Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE bit set.", "cve_priority": "medium", "cve_public_date": "2025-07-04 11:15:00 UTC" }, { "cve": "CVE-2025-38265", "url": "https://ubuntu.com/security/CVE-2025-38265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: jsm: fix NPE during jsm_uart_port_init No device was set which caused serial_base_ctrl_add to crash. BUG: kernel NULL pointer dereference, address: 0000000000000050 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1 Debian 6.12.25-1 RIP: 0010:serial_base_ctrl_add+0x96/0x120 Call Trace: serial_core_register_port+0x1a0/0x580 ? __setup_irq+0x39c/0x660 ? __kmalloc_cache_noprof+0x111/0x310 jsm_uart_port_init+0xe8/0x180 [jsm] jsm_probe_one+0x1f4/0x410 [jsm] local_pci_probe+0x42/0x90 pci_device_probe+0x22f/0x270 really_probe+0xdb/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8c/0xe0 bus_add_driver+0x112/0x1f0 driver_register+0x72/0xd0 jsm_init_module+0x36/0xff0 [jsm] ? __pfx_jsm_init_module+0x10/0x10 [jsm] do_one_initcall+0x58/0x310 do_init_module+0x60/0x230 Tested with Digi Neo PCIe 8 port card.", "cve_priority": "medium", "cve_public_date": "2025-07-10 08:15:00 UTC" }, { "cve": "CVE-2025-38053", "url": "https://ubuntu.com/security/CVE-2025-38053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix null-ptr-deref in idpf_features_check idpf_features_check is used to validate the TX packet. skb header length is compared with the hardware supported value received from the device control plane. The value is stored in the adapter structure and to access it, vport pointer is used. During reset all the vports are released and the vport pointer that the netdev private structure points to is NULL. To avoid null-ptr-deref, store the max header length value in netdev private structure. This also helps to cache the value and avoid accessing adapter pointer in hot path. BUG: kernel NULL pointer dereference, address: 0000000000000068 ... RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf] Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38055", "url": "https://ubuntu.com/security/CVE-2025-38055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq Currently, using PEBS-via-PT with a sample frequency instead of a sample period, causes a segfault. For example: BUG: kernel NULL pointer dereference, address: 0000000000000195 ? __die_body.cold+0x19/0x27 ? page_fault_oops+0xca/0x290 ? exc_page_fault+0x7e/0x1b0 ? asm_exc_page_fault+0x26/0x30 ? intel_pmu_pebs_event_update_no_drain+0x40/0x60 ? intel_pmu_pebs_event_update_no_drain+0x32/0x60 intel_pmu_drain_pebs_icl+0x333/0x350 handle_pmi_common+0x272/0x3c0 intel_pmu_handle_irq+0x10a/0x2e0 perf_event_nmi_handler+0x2a/0x50 That happens because intel_pmu_pebs_event_update_no_drain() assumes all the pebs_enabled bits represent counter indexes, which is not always the case. In this particular case, bits 60 and 61 are set for PEBS-via-PT purposes. The behaviour of PEBS-via-PT with sample frequency is questionable because although a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is not adjusted anyway. Putting that aside, fix intel_pmu_pebs_event_update_no_drain() by passing the mask of counter bits instead of 'size'. Note, prior to the Fixes commit, 'size' would be limited to the maximum counter index, so the issue was not hit.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38057", "url": "https://ubuntu.com/security/CVE-2025-38057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38060", "url": "https://ubuntu.com/security/CVE-2025-38060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: copy_verifier_state() should copy 'loop_entry' field The bpf_verifier_state.loop_entry state should be copied by copy_verifier_state(). Otherwise, .loop_entry values from unrelated states would poison env->cur_state. Additionally, env->stack should not contain any states with .loop_entry != NULL. The states in env->stack are yet to be verified, while .loop_entry is set for states that reached an equivalent state. This means that env->cur_state->loop_entry should always be NULL after pop_stack(). See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix. This change has some verification performance impact for selftests: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- ------------- arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%) And significant negative impact for sched_ext: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------ bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scx_qmap.bpf.o qmap_dispatch ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38098", "url": "https://ubuntu.com/security/CVE-2025-38098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Don't treat wb connector as physical in create_validate_stream_for_sink Don't try to operate on a drm_wb_connector as an amdgpu_dm_connector. While dereferencing aconnector->base will \"work\" it's wrong and might lead to unknown bad things. Just... don't.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38099", "url": "https://ubuntu.com/security/CVE-2025-38099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken A SCO connection without the proper voice_setting can cause the controller to lock up.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38073", "url": "https://ubuntu.com/security/CVE-2025-38073", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38051", "url": "https://ubuntu.com/security/CVE-2025-38051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_fill_dirent There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 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 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== POC is available in the link [1]. The problem triggering process is as follows: Process 1 Process 2 ----------------------------------- ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38077", "url": "https://ubuntu.com/security/CVE-2025-38077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store() If the 'buf' array received from the user contains an empty string, the 'length' variable will be zero. Accessing the 'buf' array element with index 'length - 1' will result in a buffer overflow. Add a check for an empty string. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38078", "url": "https://ubuntu.com/security/CVE-2025-38078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race of buffer access at PCM OSS layer The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38003", "url": "https://ubuntu.com/security/CVE-2025-38003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu read protection for procfs content When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF). As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.", "cve_priority": "medium", "cve_public_date": "2025-06-08 11:15:00 UTC" }, { "cve": "CVE-2025-38004", "url": "https://ubuntu.com/security/CVE-2025-38004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.", "cve_priority": "medium", "cve_public_date": "2025-06-08 11:15:00 UTC" }, { "cve": "CVE-2025-38031", "url": "https://ubuntu.com/security/CVE-2025-38031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: do not leak refcount in reorder_work A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented. Fix this by checking the return value of queue_work() and decrementing the refcount when necessary. Resolves: Unreferenced object 0xffff9d9f421e3d80 (size 192): comm \"cryptomgr_probe\", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38079", "url": "https://ubuntu.com/security/CVE-2025-38079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_hash - fix double free in hash_accept If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38052", "url": "https://ubuntu.com/security/CVE-2025-38052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38097", "url": "https://ubuntu.com/security/CVE-2025-38097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used \"recently\", but it's a lot more complex than just not caching the socket.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-38058", "url": "https://ubuntu.com/security/CVE-2025-38058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38059", "url": "https://ubuntu.com/security/CVE-2025-38059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid NULL pointer dereference if no valid csum tree [BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace: BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Call Trace: scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE] Mount option \"rescue=idatacsums\" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification. Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all. This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash. [FIX] Check both extent and csum tree root before doing any tree search.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38034", "url": "https://ubuntu.com/security/CVE-2025-38034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref btrfs_prelim_ref() calls the old and new reference variables in the incorrect order. This causes a NULL pointer dereference because oldref is passed as NULL to trace_btrfs_prelim_ref_insert(). Note, trace_btrfs_prelim_ref_insert() is being called with newref as oldref (and oldref as NULL) on purpose in order to print out the values of newref. To reproduce: echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable Perform some writeback operations. Backtrace: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38035", "url": "https://ubuntu.com/security/CVE-2025-38035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: don't restore null sk_state_change queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if the TCP connection isn't established when nvmet_tcp_set_queue_sock() is called then queue->state_change isn't set and sock->sk->sk_state_change isn't replaced. As such we don't need to restore sock->sk->sk_state_change if queue->state_change is NULL. This avoids NULL pointer dereferences such as this: [ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode [ 286.463796][ C0] #PF: error_code(0x0010) - not-present page [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0 [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary) [ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 286.467147][ C0] RIP: 0010:0x0 [ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246 [ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43 [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100 [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3 [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268 [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000 [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0 [ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 286.475453][ C0] Call Trace: [ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440 [ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60 [ 286.478174][ C0] ? __build_skb_around+0x234/0x330 [ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10 [ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0 [ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30 [ 286.482769][ C0] ? ktime_get+0x66/0x150 [ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050 [ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0 [ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10 [ 286.486917][ C0] ? lock_release+0x217/0x2c0 [ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0 [ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30 [ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0 [ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10 [ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10 [ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack] [ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370 [ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420 [ 286.494268][ C0] ip_local_deliver+0x168/0x430 [ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10 [ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20 [ 286.496806][ C0] ? lock_release+0x217/0x2c0 [ 286.497414][ C0] ip_rcv+0x455/0x6e0 [ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10 [ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38037", "url": "https://ubuntu.com/security/CVE-2025-38037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Annotate FDB data races The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2]. Suppress these reports by annotating these accesses using READ_ONCE() / WRITE_ONCE(). [1] BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f Reported by Kernel Concurrency Sanitizer on: CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38039", "url": "https://ubuntu.com/security/CVE-2025-38039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled When attempting to enable MQPRIO while HTB offload is already configured, the driver currently returns `-EINVAL` and triggers a `WARN_ON`, leading to an unnecessary call trace. Update the code to handle this case more gracefully by returning `-EOPNOTSUPP` instead, while also providing a helpful user message.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38080", "url": "https://ubuntu.com/security/CVE-2025-38080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase block_sequence array size [Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash. [How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38040", "url": "https://ubuntu.com/security/CVE-2025-38040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: mctrl_gpio: split disable_ms into sync and no_sync APIs The following splat has been observed on a SAMA5D27 platform using atmel_serial: BUG: sleeping function called from invalid context at kernel/irq/manage.c:738 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0 preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<00000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7bec softirqs last enabled at (0): [] copy_process+0x1ca0/0x7bec softirqs last disabled at (0): [<00000000>] 0x0 CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74 Hardware name: Atmel SAMA5 Workqueue: hci0 hci_power_on [bluetooth] Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28 This warning is emitted when trying to toggle, at the highest level, some flow control (with serdev_device_set_flow_control) in a device driver. At the lowest level, the atmel_serial driver is using serial_mctrl_gpio lib to enable/disable the corresponding IRQs accordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to disable_irq (called in mctrl_gpio_disable_ms) being possibly called in some atomic context (some tty drivers perform modem lines configuration in regions protected by port lock). Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one and a blocking one. Replace mctrl_gpio_disable_ms calls with the relevant version depending on whether the call is protected by some port lock.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38061", "url": "https://ubuntu.com/security/CVE-2025-38061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix access outside of user given buffer in pktgen_thread_write() Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer).", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38062", "url": "https://ubuntu.com/security/CVE-2025-38062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie The IOMMU translation for MSI message addresses has been a 2-step process, separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address. This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached. Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the \"container\" after starting up. However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()). This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs. Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor. The other UAF related to iommu_get_domain_for_dev() will be addressed in patch \"iommu: Make iommu_dma_prepare_msi() into a generic operation\" by using the IOMMU group mutex.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38063", "url": "https://ubuntu.com/security/CVE-2025-38063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix unconditional IO throttle caused by REQ_PREFLUSH When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush() generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, which causes the flush_bio to be throttled by wbt_wait(). An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: \"kworker/u260:0\" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4 After commit 2def2845cc33 (\"xfs: don't allow log IO to be throttled\"), the metadata submitted by xlog_write_iclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled. Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes wbt_should_throttle() return false to avoid wbt_wait().", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38043", "url": "https://ubuntu.com/security/CVE-2025-38043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Set dma_mask for ffa devices Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning: WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38044", "url": "https://ubuntu.com/security/CVE-2025-38044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: set device_caps for 417 The video_device for the MPEG encoder did not set device_caps. Add this, otherwise the video device can't be registered (you get a WARN_ON instead). Not seen before since currently 417 support is disabled, but I found this while experimenting with it.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38065", "url": "https://ubuntu.com/security/CVE-2025-38065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: Do not truncate file size 'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38066", "url": "https://ubuntu.com/security/CVE-2025-38066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: prevent BUG_ON by blocking retries on failed device resumes A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object. Reproduce steps: 1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata. cat <> cmeta.xml EOF dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta 2. wipe the second array block of the mapping array to simulate data degradations. mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\ 2>/dev/null | hexdump -e '1/8 \"%u\\n\"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\ 2>/dev/null | hexdump -e '1/8 \"%u\\n\"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try bringing up the cache device. The resume is expected to fail due to the broken array block. dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dmsetup create cache --notable dmsetup load cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup resume cache 4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings. dmsetup resume cache Kernel logs: (snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570 Fix by disallowing resume operations for devices that failed the initial attempt.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38068", "url": "https://ubuntu.com/security/CVE-2025-38068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: lzo - Fix compression buffer overrun Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller. Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38045", "url": "https://ubuntu.com/security/CVE-2025-38045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix debug actions order The order of actions taken for debug was implemented incorrectly. Now we implemented the dump split and do the FW reset only in the middle of the dump (rather than the FW killing itself on error.) As a result, some of the actions taken when applying the config will now crash the device, so we need to fix the order.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38071", "url": "https://ubuntu.com/security/CVE-2025-38071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Check return value from memblock_phys_alloc_range() At least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of contiguous free memory available at this point, the kernel will crash and burn because memblock_phys_alloc_range() returns 0 on failure, which leads memblock_phys_free() to throw the first 4 MiB of physical memory to the wolves. At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine without the weird reserve allocation.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38072", "url": "https://ubuntu.com/security/CVE-2025-38072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Fix divide error in nd_label_data_init() If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Code and flow: 1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer is set to zero (nvdimm driver): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) A subsequent DIV_ROUND_UP() causes a division by zero: drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Fix this by checking the config size parameter by extending an existing check.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38081", "url": "https://ubuntu.com/security/CVE-2025-38081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi-rockchip: Fix register out of bounds access Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38074", "url": "https://ubuntu.com/security/CVE-2025-38074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: protect vq->log_used with vq->mutex The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); \t\t\t\t QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38048", "url": "https://ubuntu.com/security/CVE-2025-38048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_ring: Fix data race by tagging event_triggered as racy for KCSAN syzbot reports a data-race when accessing the event_triggered, here is the simplified stack when the issue occurred: ================================================================== BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayed write to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3800 [inline] read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline] value changed: 0x01 -> 0x00 ================================================================== When the data race occurs, the function virtqueue_enable_cb_delayed() sets event_triggered to false, and virtqueue_disable_cb_split/packed() reads it as false due to the race condition. Since event_triggered is an unreliable hint used for optimization, this should only cause the driver temporarily suggest that the device not send an interrupt notification when the event index is used. Fix this KCSAN reported data-race issue by explicitly tagging the access as data_racy.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38075", "url": "https://ubuntu.com/security/CVE-2025-38075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix timeout on deleted connection NOPIN response timer may expire on a deleted connection and crash with such logs: Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 That is because nopin response timer may be re-started on nopin timer expiration. Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-37968", "url": "https://ubuntu.com/security/CVE-2025-37968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: opt3001: fix deadlock due to concurrent flag access The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-38011", "url": "https://ubuntu.com/security/CVE-2025-38011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: csa unmap use uninterruptible lock After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace. Change to use uninterruptible wait lock fix the issue. WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu] Call Trace: drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.isra.0+0x65/0x70 [drm] drm_release+0x6a/0x120 [drm] amdgpu_drm_release+0x51/0x60 [amdgpu] __fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0 (cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-21931", "url": "https://ubuntu.com/security/CVE-2025-21931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio Commit b15c87263a69 (\"hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page. However folio lock must be held before calling try_to_unmap. Add it to fix this problem. Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2025-37960", "url": "https://ubuntu.com/security/CVE-2025-37960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memblock: Accept allocated memory before use in memblock_double_array() When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest: RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b Mitigate this by calling accept_memory() on the memory range returned before the slab is available. Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37967", "url": "https://ubuntu.com/security/CVE-2025-37967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix deadlock This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-22102", "url": "https://ubuntu.com/security/CVE-2025-22102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix kernel panic during FW release This fixes a kernel panic seen during release FW in a stress test scenario where WLAN and BT FW download occurs simultaneously, and due to a HW bug, chip sends out only 1 bootloader signatures. When driver receives the bootloader signature, it enters FW download mode, but since no consequtive bootloader signatures seen, FW file is not requested. After 60 seconds, when FW download times out, release_firmware causes a kernel panic. [ 2601.949184] Unable to handle kernel paging request at virtual address 0000312e6f006573 [ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000 [ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000 [ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP [ 2601.992091] Modules linked in: algif_hash algif_skcipher af_alg btnxpuart(O) pciexxx(O) mlan(O) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce snd_soc_fsl_easrc snd_soc_fsl_asoc_card imx8_media_dev(C) snd_soc_fsl_micfil polyval_generic snd_soc_fsl_xcvr snd_soc_fsl_sai snd_soc_imx_audmux snd_soc_fsl_asrc snd_soc_imx_card snd_soc_imx_hdmi snd_soc_fsl_aud2htx snd_soc_fsl_utils imx_pcm_dma dw_hdmi_cec flexcan can_dev [ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G C O 6.6.23-lts-next-06236-gb586a521770e #1 [ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2602.010191] pc : _raw_spin_lock+0x34/0x68 [ 2602.010201] lr : free_fw_priv+0x20/0xfc [ 2602.020561] sp : ffff800089363b30 [ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000 [ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000 [ 2602.020577] x23: ffff0000dc856f38 [ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000 [ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000 [ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480 [ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002 [ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30 [ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000 [ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001 [ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573 [ 2602.083354] Call trace: [ 2602.083356] _raw_spin_lock+0x34/0x68 [ 2602.083364] release_firmware+0x48/0x6c [ 2602.083370] nxp_setup+0x3c4/0x540 [btnxpuart] [ 2602.083383] hci_dev_open_sync+0xf0/0xa34 [ 2602.083391] hci_dev_open+0xd8/0x178 [ 2602.083399] hci_sock_ioctl+0x3b0/0x590 [ 2602.083405] sock_do_ioctl+0x60/0x118 [ 2602.083413] sock_ioctl+0x2f4/0x374 [ 2602.091430] __arm64_sys_ioctl+0xac/0xf0 [ 2602.091437] invoke_syscall+0x48/0x110 [ 2602.091445] el0_svc_common.constprop.0+0xc0/0xe0 [ 2602.091452] do_el0_svc+0x1c/0x28 [ 2602.091457] el0_svc+0x40/0xe4 [ 2602.091465] el0t_64_sync_handler+0x120/0x12c [ 2602.091470] el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38008", "url": "https://ubuntu.com/security/CVE-2025-38008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix race condition in unaccepted memory handling The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machinery detects it: WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 The comment around the WARN() explains the problem: \t/* \t * Warn about the '-1' case though; since that means a \t * decrement is concurrent with a first (0->1) increment. IOW \t * people are trying to disable something that wasn't yet fully \t * enabled. This suggests an ordering problem on the user side. \t */ The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38014", "url": "https://ubuntu.com/security/CVE-2025-38014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Refactor remove call with idxd_cleanup() helper The idxd_cleanup() helper cleans up perfmon, interrupts, internals and so on. Refactor remove call with the idxd_cleanup() helper to avoid code duplication. Note, this also fixes the missing put_device() for idxd groups, enginces and wqs.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38015", "url": "https://ubuntu.com/security/CVE-2025-38015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix memory leak in error handling path of idxd_alloc Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38005", "url": "https://ubuntu.com/security/CVE-2025-38005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma: Add missing locking Recent kernels complain about a missing lock in k3-udma.c when the lock validator is enabled: [ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28 [ 4.144867] Hardware name: pp-v12 (DT) [ 4.148648] Workqueue: events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udma_start.isra.0+0x34/0x238 [ 4.165227] lr : udma_start.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udma_start.isra.0+0x34/0x238 [ 4.251509] udma_check_tx_completion+0xd0/0xdc [ 4.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] ret_from_fork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28 [ 4.311559] ---[ end trace 0000000000000000 ]--- This commit adds the missing locking.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38009", "url": "https://ubuntu.com/security/CVE-2025-38009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: disable napi on driver removal A warning on driver removal started occurring after commit 9dd05df8403b (\"net: warn if NAPI instance wasn't shut down\"). Disable tx napi before deleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Tested with mt7921e but the same pattern can be actually applied to other mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled in their *_dma_init() functions and only toggled off and on again inside their suspend/resume/reset paths. So it should be okay to disable tx napi in such a generic way. Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38010", "url": "https://ubuntu.com/security/CVE-2025-38010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as: [ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270 The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 (\"xhci: tegra: USB2 pad power controls\"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count. To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually. With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles. The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38095", "url": "https://ubuntu.com/security/CVE-2025-38095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-buf: insert memory barrier before updating num_fences smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered.", "cve_priority": "medium", "cve_public_date": "2025-07-03 08:15:00 UTC" }, { "cve": "CVE-2025-38018", "url": "https://ubuntu.com/security/CVE-2025-38018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix kernel panic when alloc_page failed We cannot set frag_list to NULL pointer when alloc_page failed. It will be used in tls_strp_check_queue_ok when the next time tls_strp_read_sock is called. This is because we don't reset full_len in tls_strp_flush_anchor_copy() so the recv path will try to continue handling the partial record on the next call but we dettached the rcvq from the frag list. Alternative fix would be to reset full_len. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Call trace: tls_strp_check_rcv+0x128/0x27c tls_strp_data_ready+0x34/0x44 tls_data_ready+0x3c/0x1f0 tcp_data_ready+0x9c/0xe4 tcp_data_queue+0xf6c/0x12d0 tcp_rcv_established+0x52c/0x798", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38019", "url": "https://ubuntu.com/security/CVE-2025-38019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices: # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP (Note that the neighbor is not marked with 'offload') When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one: # devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted: # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1 Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38013", "url": "https://ubuntu.com/security/CVE-2025-38013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request Make sure that n_channels is set after allocating the struct cfg80211_registered_device::int_scan_req member. Seen with syzkaller: UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]') This was missed in the initial conversions because I failed to locate the allocation likely due to the \"sizeof(void *)\" not matching the \"channels\" array type.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38027", "url": "https://ubuntu.com/security/CVE-2025-38027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: max20086: fix invalid memory access max20086_parse_regulators_dt() calls of_regulator_match() using an array of struct of_regulator_match allocated on the stack for the matches argument. of_regulator_match() calls devm_of_regulator_put_matches(), which calls devres_alloc() to allocate a struct devm_of_regulator_matches which will be de-allocated using devm_of_regulator_put_matches(). struct devm_of_regulator_matches is populated with the stack allocated matches array. If the device fails to probe, devm_of_regulator_put_matches() will be called and will try to call of_node_put() on that stack pointer, generating the following dmesg entries: max20086 6-0028: Failed to read DEVICE_ID reg: -121 kobject: '\\xc0$\\xa5\\x03' (000000002cebcb7a): is not initialized, yet kobject_put() is being called. Followed by a stack trace matching the call flow described above. Switch to allocating the matches array using devm_kcalloc() to avoid accessing the stack pointer long after it's out of scope. This also has the advantage of allowing multiple max20086 to probe without overriding the data stored inside the global of_regulator_match.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38020", "url": "https://ubuntu.com/security/CVE-2025-38020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Disable MACsec offload for uplink representor profile MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features. If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set. Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features(). Kernel log: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sen ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38094", "url": "https://ubuntu.com/security/CVE-2025-38094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cadence: macb: Fix a possible deadlock in macb_halt_tx. There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.", "cve_priority": "medium", "cve_public_date": "2025-07-03 08:15:00 UTC" }, { "cve": "CVE-2025-38006", "url": "https://ubuntu.com/security/CVE-2025-38006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox \"ip addr show\". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-37992", "url": "https://ubuntu.com/security/CVE-2025-37992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: Flush gso_skb list too during ->change() Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.", "cve_priority": "medium", "cve_public_date": "2025-05-26 15:15:00 UTC" }, { "cve": "CVE-2025-38023", "url": "https://ubuntu.com/security/CVE-2025-38023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: handle failure of nfs_get_lock_context in unlock path When memory is insufficient, the allocation of nfs_lock_context in nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM) as valid and proceed to execute rpc_run_task(), this will trigger a NULL pointer dereference in nfs4_locku_prepare. For example: BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]--- Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and return NULL to terminate subsequent rpc_run_task, preventing NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38007", "url": "https://ubuntu.com/security/CVE-2025-38007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Add NULL check in uclogic_input_configured() devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-38024", "url": "https://ubuntu.com/security/CVE-2025-38024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur. The solution is to let rxe_cleanup do all the work.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-37957", "url": "https://ubuntu.com/security/CVE-2025-37957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception Previously, commit ed129ec9057f (\"KVM: x86: forcibly leave nested mode on vCPU reset\") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM). This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault The issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do _something_ sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI. So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [sean: massage changelog, make it clear this isn't architectural behavior]", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37963", "url": "https://ubuntu.com/security/CVE-2025-37963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37948", "url": "https://ubuntu.com/security/CVE-2025-37948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37994", "url": "https://ubuntu.com/security/CVE-2025-37994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix NULL pointer access This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.", "cve_priority": "medium", "cve_public_date": "2025-05-29 14:15:00 UTC" }, { "cve": "CVE-2025-37995", "url": "https://ubuntu.com/security/CVE-2025-37995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.", "cve_priority": "medium", "cve_public_date": "2025-05-29 14:15:00 UTC" }, { "cve": "CVE-2025-37949", "url": "https://ubuntu.com/security/CVE-2025-37949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xenbus: Use kref to track req lifetime Marek reported seeing a NULL pointer fault in the xenbus_thread callstack: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: e030:__wake_up_common+0x4c/0x180 Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0 process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems like it was xs_wake_up() in this case. It seems like req may have woken up the xs_wait_for_reply(), which kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed data. Linux Device Drivers 2nd edition states: \"Normally, a wake_up call can cause an immediate reschedule to happen, meaning that other processes might run before wake_up returns.\" ... which would match the behaviour observed. Change to keeping two krefs on each request. One for the caller, and one for xenbus_thread. Each will kref_put() when finished, and the last will free it. This use of kref matches the description in Documentation/core-api/kref.rst", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37954", "url": "https://ubuntu.com/security/CVE-2025-37954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Avoid race in open_cached_dir with lease breaks A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs. Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37951", "url": "https://ubuntu.com/security/CVE-2025-37951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Add job to pending list if the reset was skipped When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1] and [2]. Similarly to commit 704d3d60fec4 (\"drm/etnaviv: don't block scheduler when GPU is still active\"), this patch ensures the job is put back on the pending list when extending the timeout.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37969", "url": "https://ubuntu.com/security/CVE-2025-37969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37970", "url": "https://ubuntu.com/security/CVE-2025-37970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37972", "url": "https://ubuntu.com/security/CVE-2025-37972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: mtk-pmic-keys - fix possible null pointer dereference In mtk_pmic_keys_probe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer. Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37959", "url": "https://ubuntu.com/security/CVE-2025-37959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Scrub packet on bpf_redirect_peer When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be \"misused\" in another namespace. As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2, In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption. This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37961", "url": "https://ubuntu.com/security/CVE-2025-37961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix uninit-value for saddr in do_output_route4 syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 (\"ipvs: do not use random local source address for tunnels\") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37998", "url": "https://ubuntu.com/security/CVE-2025-37998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.", "cve_priority": "medium", "cve_public_date": "2025-05-29 14:15:00 UTC" }, { "cve": "CVE-2025-37952", "url": "https://ubuntu.com/security/CVE-2025-37952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix UAF in __close_file_table_ids A use-after-free is possible if one thread destroys the file via __ksmbd_close_fd while another thread holds a reference to it. The existing checks on fp->refcount are not sufficient to prevent this. The fix takes ft->lock around the section which removes the file from the file table. This prevents two threads acquiring the same file pointer via __close_file_table_ids, as well as the other functions which retrieve a file from the IDR and which already use this same lock.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37947", "url": "https://ubuntu.com/security/CVE-2025-37947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds stream writes by validating *pos ksmbd_vfs_stream_write() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (v_len). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write. This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37956", "url": "https://ubuntu.com/security/CVE-2025-37956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent rename with empty string Client can send empty newname string to ksmbd server. It will cause a kernel oops from d_alloc. This patch return the error when attempting to rename a file or directory with an empty new name string.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37973", "url": "https://ubuntu.com/security/CVE-2025-37973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation Currently during the multi-link element defragmentation process, the multi-link element length added to the total IEs length when calculating the length of remaining IEs after the multi-link element in cfg80211_defrag_mle(). This could lead to out-of-bounds access if the multi-link element or its corresponding fragment elements are the last elements in the IEs buffer. To address this issue, correctly calculate the remaining IEs length by deducting the multi-link element end offset from total IEs end offset.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37920", "url": "https://ubuntu.com/security/CVE-2025-37920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37900", "url": "https://ubuntu.com/security/CVE-2025-37900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu: Fix two issues in iommu_copy_struct_from_user() In the review for iommu_copy_struct_to_user() helper, Matt pointed out that a NULL pointer should be rejected prior to dereferencing it: https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com And Alok pointed out a typo at the same time: https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com Since both issues were copied from iommu_copy_struct_from_user(), fix them first in the current header.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37931", "url": "https://ubuntu.com/security/CVE-2025-37931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: adjust subpage bit start based on sectorsize When running machines with 64k page size and a 16k nodesize we started seeing tree log corruption in production. This turned out to be because we were not writing out dirty blocks sometimes, so this in fact affects all metadata writes. When writing out a subpage EB we scan the subpage bitmap for a dirty range. If the range isn't dirty we do \tbit_start++; to move onto the next bit. The problem is the bitmap is based on the number of sectors that an EB has. So in this case, we have a 64k pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4 bits for every node. With a 64k page size we end up with 4 nodes per page. To make this easier this is how everything looks [0 16k 32k 48k ] logical address [0 4 8 12 ] radix tree offset [ 64k page ] folio [ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers [ | | | | | | | | | | | | | | | | ] bitmap Now we use all of our addressing based on fs_info->sectorsize_bits, so as you can see the above our 16k eb->start turns into radix entry 4. When we find a dirty range for our eb, we correctly do bit_start += sectors_per_node, because if we start at bit 0, the next bit for the next eb is 4, to correspond to eb->start 16k. However if our range is clean, we will do bit_start++, which will now put us offset from our radix tree entries. In our case, assume that the first time we check the bitmap the block is not dirty, we increment bit_start so now it == 1, and then we loop around and check again. This time it is dirty, and we go to find that start using the following equation \tstart = folio_start + bit_start * fs_info->sectorsize; so in the case above, eb->start 0 is now dirty, and we calculate start as \t0 + 1 * fs_info->sectorsize = 4096 \t4096 >> 12 = 1 Now we're looking up the radix tree for 1, and we won't find an eb. What's worse is now we're using bit_start == 1, so we do bit_start += sectors_per_node, which is now 5. If that eb is dirty we will run into the same thing, we will look at an offset that is not populated in the radix tree, and now we're skipping the writeout of dirty extent buffers. The best fix for this is to not use sectorsize_bits to address nodes, but that's a larger change. Since this is a fs corruption problem fix it simply by always using sectors_per_node to increment the start bit.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37903", "url": "https://ubuntu.com/security/CVE-2025-37903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix slab-use-after-free in hdcp The HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connector objects without incrementing the kref reference counts. When using a USB-C dock, and the dock is unplugged, the corresponding amdgpu_dm_connector objects are freed, creating dangling pointers in the HDCP code. When the dock is plugged back, the dangling pointers are dereferenced, resulting in a slab-use-after-free: [ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10 [ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233 [ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024 [ 66.776186] Workqueue: events event_property_validate [amdgpu] [ 66.776494] Call Trace: [ 66.776496] [ 66.776497] dump_stack_lvl+0x70/0xa0 [ 66.776504] print_report+0x175/0x555 [ 66.776507] ? __virt_addr_valid+0x243/0x450 [ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0 [ 66.776515] kasan_report+0xeb/0x1c0 [ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.777121] __asan_report_load4_noabort+0x14/0x20 [ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.777342] ? __lock_acquire+0x6b40/0x6b40 [ 66.777347] ? enable_assr+0x250/0x250 [amdgpu] [ 66.777571] process_one_work+0x86b/0x1510 [ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0 [ 66.777578] ? assign_work+0x16b/0x280 [ 66.777580] ? lock_is_held_type+0xa3/0x130 [ 66.777583] worker_thread+0x5c0/0xfa0 [ 66.777587] ? process_one_work+0x1510/0x1510 [ 66.777588] kthread+0x3a2/0x840 [ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777594] ? trace_hardirqs_on+0x4f/0x60 [ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60 [ 66.777599] ? calculate_sigpending+0x77/0xa0 [ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777605] ret_from_fork+0x40/0x90 [ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777609] ret_from_fork_asm+0x11/0x20 [ 66.777614] [ 66.777643] Allocated by task 10: [ 66.777646] kasan_save_stack+0x39/0x60 [ 66.777649] kasan_save_track+0x14/0x40 [ 66.777652] kasan_save_alloc_info+0x37/0x50 [ 66.777655] __kasan_kmalloc+0xbb/0xc0 [ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0 [ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu] [ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper] [ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper] [ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper] [ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper] [ 66.777917] process_one_work+0x86b/0x1510 [ 66.777919] worker_thread+0x5c0/0xfa0 [ 66.777922] kthread+0x3a2/0x840 [ 66.777925] ret_from_fork+0x40/0x90 [ 66.777927] ret_from_fork_asm+0x11/0x20 [ 66.777932] Freed by task 1713: [ 66.777935] kasan_save_stack+0x39/0x60 [ 66.777938] kasan_save_track+0x14/0x40 [ 66.777940] kasan_save_free_info+0x3b/0x60 [ 66.777944] __kasan_slab_free+0x52/0x70 [ 66.777946] kfree+0x13f/0x4b0 [ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu] [ 66.778179] drm_connector_free+0x7d/0xb0 [ 66.778184] drm_mode_object_put.part.0+0xee/0x160 [ 66.778188] drm_mode_object_put+0x37/0x50 [ 66.778191] drm_atomic_state_default_clear+0x220/0xd60 [ 66.778194] __drm_atomic_state_free+0x16e/0x2a0 [ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0 [ 66.778200] drm_ioctl_kernel+0x17a/0x310 [ 66.778203] drm_ioctl+0x584/0xd10 [ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu] [ 66.778375] __x64_sys_ioctl+0x139/0x1a0 [ 66.778378] x64_sys_call+0xee7/0xfb0 [ 66.778381] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37905", "url": "https://ubuntu.com/security/CVE-2025-37905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Balance device refcount when destroying devices Using device_find_child() to lookup the proper SCMI device to destroy causes an unbalance in device refcount, since device_find_child() calls an implicit get_device(): this, in turns, inhibits the call of the provided release methods upon devices destruction. As a consequence, one of the structures that is not freed properly upon destruction is the internal struct device_private dev->p populated by the drivers subsystem core. KMemleak detects this situation since loading/unloding some SCMI driver causes related devices to be created/destroyed without calling any device_release method. unreferenced object 0xffff00000f583800 (size 512): comm \"insmod\", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158 $ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0 device_add+0x954/0x12d0: kmalloc_noprof at include/linux/slab.h:901 (inlined by) kzalloc_noprof at include/linux/slab.h:1037 (inlined by) device_private_init at drivers/base/core.c:3510 (inlined by) device_add at drivers/base/core.c:3561 Balance device refcount by issuing a put_device() on devices found via device_find_child().", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37933", "url": "https://ubuntu.com/security/CVE-2025-37933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeon_ep: Fix host hang issue during device reboot When the host loses heartbeat messages from the device, the driver calls the device-specific ndo_stop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndo_stop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndo_stop is not called.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37909", "url": "https://ubuntu.com/security/CVE-2025-37909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Fix memleak issue when GSO enabled Always map the `skb` to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37911", "url": "https://ubuntu.com/security/CVE-2025-37911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix out-of-bound memcpy() during ethtool -w When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption: BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80 ... This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf. In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information. This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37935", "url": "https://ubuntu.com/security/CVE-2025-37935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix SER panic with 4GB+ RAM If the mtk_poll_rx() function detects the MTK_RESETTING flag, it will jump to release_desc and refill the high word of the SDP on the 4GB RFB. Subsequently, mtk_rx_clean will process an incorrect SDP, leading to a panic. Add patch from MediaTek's SDK to resolve this.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37891", "url": "https://ubuntu.com/security/CVE-2025-37891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: Fix buffer overflow at UMP SysEx message conversion The conversion function from MIDI 1.0 to UMP packet contains an internal buffer to keep the incoming MIDI bytes, and its size is 4, as it was supposed to be the max size for a MIDI1 UMP packet data. However, the implementation overlooked that SysEx is handled in a different format, and it can be up to 6 bytes, as found in do_convert_to_ump(). It leads eventually to a buffer overflow, and may corrupt the memory when a longer SysEx message is received. The fix is simply to extend the buffer size to 6 to fit with the SysEx UMP message.", "cve_priority": "medium", "cve_public_date": "2025-05-19 08:15:00 UTC" }, { "cve": "CVE-2025-37912", "url": "https://ubuntu.com/security/CVE-2025-37912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr() As mentioned in the commit baeb705fd6a7 (\"ice: always check VF VSI pointer values\"), we need to perform a null pointer check on the return value of ice_get_vf_vsi() before using it.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37913", "url": "https://ubuntu.com/security/CVE-2025-37913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: qfq: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of qfq, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. This patch checks whether the class was already added to the agg->active list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37914", "url": "https://ubuntu.com/security/CVE-2025-37914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37915", "url": "https://ubuntu.com/security/CVE-2025-37915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: drr: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37916", "url": "https://ubuntu.com/security/CVE-2025-37916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: remove write-after-free of client_id A use-after-free error popped up in stress testing: [Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47): [Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core] [Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70 [Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180 [Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80 [Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0 [Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80 The actual device uninit usually happens on a separate thread scheduled after this code runs, but there is no guarantee of order of thread execution, so this could be a problem. There's no actual need to clear the client_id at this point, so simply remove the offending code.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37917", "url": "https://ubuntu.com/security/CVE-2025-37917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll Use spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock and spin_unlock in mtk_star_emac driver to avoid spinlock recursion occurrence that can happen when enabling the DMA interrupts again in rx/tx poll. ``` BUG: spinlock recursion on CPU#0, swapper/0/0 lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT Hardware name: MediaTek MT8365 Open Platform EVK (DT) Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x60/0x80 dump_stack+0x18/0x24 spin_dump+0x78/0x88 do_raw_spin_lock+0x11c/0x120 _raw_spin_lock+0x20/0x2c mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac] __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x4c/0xb0 handle_fasteoi_irq+0xa0/0x1bc handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x120 do_interrupt_handler+0x50/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 regmap_mmio_read32le+0xc/0x20 (P) _regmap_bus_reg_read+0x6c/0xac _regmap_read+0x60/0xdc regmap_read+0x4c/0x80 mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac] __napi_poll+0x38/0x188 net_rx_action+0x164/0x2c0 handle_softirqs+0x100/0x244 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x20 call_on_irq_stack+0x24/0x64 do_softirq_own_stack+0x1c/0x40 __irq_exit_rcu+0xd4/0x10c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 cpuidle_enter_state+0xac/0x320 (P) cpuidle_enter+0x38/0x50 do_idle+0x1e4/0x260 cpu_startup_entry+0x34/0x3c rest_init+0xdc/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ```", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37918", "url": "https://ubuntu.com/security/CVE-2025-37918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue() A NULL pointer dereference can occur in skb_dequeue() when processing a QCA firmware crash dump on WCN7851 (0489:e0f3). [ 93.672166] Bluetooth: hci0: ACL memdump size(589824) [ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth] [ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80 The issue stems from handle_dump_pkt_qca() returning 0 even when a dump packet is successfully processed. This is because it incorrectly forwards the return value of hci_devcd_init() (which returns 0 on success). As a result, the caller (btusb_recv_acl_qca() or btusb_recv_evt_qca()) assumes the packet was not handled and passes it to hci_recv_frame(), leading to premature kfree() of the skb. Later, hci_devcd_rx() attempts to dequeue the same skb from the dump queue, resulting in a NULL pointer dereference. Fix this by: 1. Making handle_dump_pkt_qca() return 0 on success and negative errno on failure, consistent with kernel conventions. 2. Splitting dump packet detection into separate functions for ACL and event packets for better structure and readability. This ensures dump packets are properly identified and consumed, avoiding double handling and preventing NULL pointer access.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37921", "url": "https://ubuntu.com/security/CVE-2025-37921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: Fix unlocked deletion of default FDB entry When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 (\"vxlan: Create wrappers for FDB lookup\"). Reproducer: # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0 Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it. [1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Call Trace: __vxlan_fdb_delete+0xbe/0x560 vxlan_vni_delete_group+0x2ba/0x940 vxlan_vni_del.isra.0+0x15f/0x580 vxlan_process_vni_filter+0x38b/0x7b0 vxlan_vnifilter_process+0x3bb/0x510 rtnetlink_rcv_msg+0x2f7/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37897", "url": "https://ubuntu.com/security/CVE-2025-37897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release plfxlc_mac_release() asserts that mac->lock is held. This assertion is incorrect, because even if it was possible, it would not be the valid behaviour. The function is used when probe fails or after the device is disconnected. In both cases mac->lock can not be held as the driver is not working with the device at the moment. All functions that use mac->lock unlock it just after it was held. There is also no need to hold mac->lock for plfxlc_mac_release() itself, as mac data is not affected, except for mac->flags, which is modified atomically. This bug leads to the following warning: ================================================================ WARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0 Modules linked in: CPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: usb_hub_wq hub_event RIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106 Call Trace: probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694 usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165 usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238 usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620 hub_port_connect drivers/usb/core/hub.c:5477 [inline] hub_port_connect_change drivers/usb/core/hub.c:5617 [inline] port_event drivers/usb/core/hub.c:5773 [inline] hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855 process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292 worker_thread+0xa47/0x1200 kernel/workqueue.c:2439 kthread+0x28d/0x320 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ================================================================ Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37922", "url": "https://ubuntu.com/security/CVE-2025-37922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: book3s64/radix : Align section vmemmap start address to PAGE_SIZE A vmemmap altmap is a device-provided region used to provide backing storage for struct pages. For each namespace, the altmap should belong to that same namespace. If the namespaces are created unaligned, there is a chance that the section vmemmap start address could also be unaligned. If the section vmemmap start address is unaligned, the altmap page allocated from the current namespace might be used by the previous namespace also. During the free operation, since the altmap is shared between two namespaces, the previous namespace may detect that the page does not belong to its altmap and incorrectly assume that the page is a normal page. It then attempts to free the normal page, which leads to a kernel crash. Kernel attempted to read user page (18) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000018 Faulting instruction address: 0xc000000000530c7c Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries CPU: 32 PID: 2104 Comm: ndctl Kdump: loaded Tainted: G W NIP: c000000000530c7c LR: c000000000530e00 CTR: 0000000000007ffe REGS: c000000015e57040 TRAP: 0300 Tainted: G W MSR: 800000000280b033 CR: 84482404 CFAR: c000000000530dfc DAR: 0000000000000018 DSISR: 40000000 IRQMASK: 0 GPR00: c000000000530e00 c000000015e572e0 c000000002c5cb00 c00c000101008040 GPR04: 0000000000000000 0000000000000007 0000000000000001 000000000000001f GPR08: 0000000000000005 0000000000000000 0000000000000018 0000000000002000 GPR12: c0000000001d2fb0 c0000060de6b0080 0000000000000000 c0000060dbf90020 GPR16: c00c000101008000 0000000000000001 0000000000000000 c000000125b20f00 GPR20: 0000000000000001 0000000000000000 ffffffffffffffff c00c000101007fff GPR24: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000004040201 0000000000000001 0000000000000000 c00c000101008040 NIP [c000000000530c7c] get_pfnblock_flags_mask+0x7c/0xd0 LR [c000000000530e00] free_unref_page_prepare+0x130/0x4f0 Call Trace: free_unref_page+0x50/0x1e0 free_reserved_page+0x40/0x68 free_vmemmap_pages+0x98/0xe0 remove_pte_table+0x164/0x1e8 remove_pmd_table+0x204/0x2c8 remove_pud_table+0x1c4/0x288 remove_pagetable+0x1c8/0x310 vmemmap_free+0x24/0x50 section_deactivate+0x28c/0x2a0 __remove_pages+0x84/0x110 arch_remove_memory+0x38/0x60 memunmap_pages+0x18c/0x3d0 devm_action_release+0x30/0x50 release_nodes+0x68/0x140 devres_release_group+0x100/0x190 dax_pmem_compat_release+0x44/0x80 [dax_pmem_compat] device_for_each_child+0x8c/0x100 [dax_pmem_compat_remove+0x2c/0x50 [dax_pmem_compat] nvdimm_bus_remove+0x78/0x140 [libnvdimm] device_remove+0x70/0xd0 Another issue is that if there is no altmap, a PMD-sized vmemmap page will be allocated from RAM, regardless of the alignment of the section start address. If the section start address is not aligned to the PMD size, a VM_BUG_ON will be triggered when setting the PMD-sized page to page table. In this patch, we are aligning the section vmemmap start address to PAGE_SIZE. After alignment, the start address will not be part of the current namespace, and a normal page will be allocated for the vmemmap mapping of the current section. For the remaining sections, altmaps will be allocated. During the free operation, the normal page will be correctly freed. In the same way, a PMD_SIZE vmemmap page will be allocated only if the section start address is PMD_SIZE-aligned; otherwise, it will fall back to a PAGE-sized vmemmap allocation. Without this patch ================== NS1 start NS2 start _________________________________________________________ | NS1 | NS2 | --------------------------------------------------------- | Altmap| Altmap | .....|Altmap| Altmap | ........... | NS1 | NS1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37923", "url": "https://ubuntu.com/security/CVE-2025-37923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix oob write in trace_seq_to_buffer() syzbot reported this bug: ================================================================== BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260 CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 .... ================================================================== It has been reported that trace_seq_to_buffer() tries to copy more data than PAGE_SIZE to buf. Therefore, to prevent this, we should use the smaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37924", "url": "https://ubuntu.com/security/CVE-2025-37924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37927", "url": "https://ubuntu.com/security/CVE-2025-37927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256. The same applies to the hid string with length 13 and uid string with length 250. Check the length of hid and uid strings separately to prevent buffer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37928", "url": "https://ubuntu.com/security/CVE-2025-37928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-bufio: don't schedule in atomic context A BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and try_verify_in_tasklet are enabled. [ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421 [ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4 [ 129.444740][ T934] preempt_count: 201, expected: 0 [ 129.444756][ T934] RCU nest depth: 0, expected: 0 [ 129.444781][ T934] Preemption disabled at: [ 129.444789][ T934] [] shrink_work+0x21c/0x248 [ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16! [ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0 [ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8 [ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT) [ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work [ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug] [ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c [ 129.447451][ T934] sp : ffffffc0843dbc90 [ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b [ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68 [ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900 [ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030 [ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358 [ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003 [ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400 [ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8 [ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0 [ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000 [ 129.447647][ T934] Call trace: [ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6] [ 129.447681][ T934] __might_resched+0x190/0x1a8 [ 129.447694][ T934] shrink_work+0x180/0x248 [ 129.447706][ T934] process_one_work+0x260/0x624 [ 129.447718][ T934] worker_thread+0x28c/0x454 [ 129.447729][ T934] kthread+0x118/0x158 [ 129.447742][ T934] ret_from_fork+0x10/0x20 [ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000) [ 129.447772][ T934] ---[ end trace 0000000000000000 ]--- dm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet is enabled, and __scan will be called in atomic context.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37990", "url": "https://ubuntu.com/security/CVE-2025-37990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage() The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions. Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized. Improve the error message to report more detailed error information.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37901", "url": "https://ubuntu.com/security/CVE-2025-37901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not have a corresponding MPM pin and should not be handled inside the MPM driver. The IRQ domain hierarchy is always applied, so it's required to explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but irq-qcom-mpm is currently missing the check. This is causing crashes when setting up interrupts for non-wake GPIOs: root@rb1:~# gpiomon -c gpiochip1 10 irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1 Unable to handle kernel paging request at virtual address ffff8000a1dc3820 Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT) pc : mpm_set_type+0x80/0xcc lr : mpm_set_type+0x5c/0xcc Call trace: mpm_set_type+0x80/0xcc (P) qcom_mpm_set_type+0x64/0x158 irq_chip_set_type_parent+0x20/0x38 msm_gpio_irq_set_type+0x50/0x530 __irq_set_trigger+0x60/0x184 __setup_irq+0x304/0x6bc request_threaded_irq+0xc8/0x19c edge_detector_setup+0x260/0x364 linereq_create+0x420/0x5a8 gpio_ioctl+0x2d4/0x6c0 Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that MPM is removed entirely from the hierarchy for non-wake GPIOs.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37936", "url": "https://ubuntu.com/security/CVE-2025-37936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value. When generating the MSR_IA32_PEBS_ENABLE value that will be loaded on VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE value. Consulting only the host kernel's host vs. guest masks results in running the guest with PEBS enabled even when the guest doesn't want to use PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply looking at exclude_host can't differentiate between events created by host userspace, and events created by KVM on behalf of the guest. Running the guest with PEBS unexpectedly enabled typically manifests as crashes due to a near-infinite stream of #PFs. E.g. if the guest hasn't written MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' when trying to record PEBS events. The issue is most easily reproduced by running `perf kvm top` from before commit 7b100989b4f6 (\"perf evlist: Remove __evlist__add_default\") (after which, `perf kvm top` effectively stopped using PEBS).\tThe userspace side of perf creates a guest-only PEBS event, which intel_guest_get_msrs() misconstrues a guest-*owned* PEBS event. Arguably, this is a userspace bug, as enabling PEBS on guest-only events simply cannot work, and userspace can kill VMs in many other ways (there is no danger to the host). However, even if this is considered to be bad userspace behavior, there's zero downside to perf/KVM restricting PEBS to guest-owned events. Note, commit 854250329c02 (\"KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations\") fixed the case where host userspace is profiling KVM *and* userspace, but missed the case where userspace is profiling only KVM.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37991", "url": "https://ubuntu.com/security/CVE-2025-37991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Fix double SIGFPE crash Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf(\"GOT signal %d with si_code %ld\\n\", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf(\"%lf\\n\",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@parisc:~# strace -f ./a.out execve(\"./a.out\", [\"./a.out\"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37930", "url": "https://ubuntu.com/security/CVE-2025-37930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill() Nouveau is mostly designed in a way that it's expected that fences only ever get signaled through nouveau_fence_signal(). However, in at least one other place, nouveau_fence_done(), can signal fences, too. If that happens (race) a signaled fence remains in the pending list for a while, until it gets removed by nouveau_fence_update(). Should nouveau_fence_context_kill() run in the meantime, this would be a bug because the function would attempt to set an error code on an already signaled fence. Have nouveau_fence_context_kill() check for a fence being signaled.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37986", "url": "https://ubuntu.com/security/CVE-2025-37986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: class: Invalidate USB device pointers on partner unregistration To avoid using invalid USB device pointers after a Type-C partner disconnects, this patch clears the pointers upon partner unregistration. This ensures a clean state for future connections.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37809", "url": "https://ubuntu.com/security/CVE-2025-37809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: class: Fix NULL pointer access Concurrent calls to typec_partner_unlink_device can lead to a NULL pointer dereference. This patch adds a mutex to protect USB device pointers and prevent this issue. The same mutex protects both the device pointers and the partner device registration.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37816", "url": "https://ubuntu.com/security/CVE-2025-37816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: vsc: Fix fortify-panic caused by invalid counted_by() use gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[] and the vsc-tp.c code is using this in a wrong way. len does not contain the available size in the buffer, it contains the actual packet length *without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to buf[] the fortify-panic handler gets triggered: [ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0 [ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50 ... [ 80.843175] __fortify_panic+0x9/0xb [ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw] [ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110 [ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc] [ 80.843270] mei_reset+0x11d/0x420 [mei] The easiest fix would be to just drop the counted-by but with the exception of the ack buffer in vsc_tp_xfer_helper() which only contains enough room for the packet-header, all other uses of vsc_tp_packet always use a buffer of VSC_TP_MAX_XFER_SIZE bytes for the packet. Instead of just dropping the counted-by, split the vsc_tp_packet struct definition into a header and a full-packet definition and use a fixed size buf[] in the packet definition, this way fortify-source buffer overrun checking still works when enabled.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37822", "url": "https://ubuntu.com/security/CVE-2025-37822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: uprobes: Add missing fence.i after building the XOL buffer The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions. This was found running the BPF selftests \"test_progs: uprobe_autoattach, attach_probe\" on the Spacemit K1/X60, where the uprobes tests randomly blew up.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37987", "url": "https://ubuntu.com/security/CVE-2025-37987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: Prevent possible adminq overflow/stuck condition The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion. On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW. As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37826", "url": "https://ubuntu.com/security/CVE-2025-37826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer() Add a NULL check for the returned hwq pointer by ufshcd_mcq_req_to_hwq(). This is similar to the fix in commit 74736103fb41 (\"scsi: ufs: core: Fix ufshcd_abort_one racing issue\").", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37827", "url": "https://ubuntu.com/security/CVE-2025-37827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: return EIO on RAID1 block group write pointer mismatch There was a bug report about a NULL pointer dereference in __btrfs_add_free_space_zoned() that ultimately happens because a conversion from the default metadata profile DUP to a RAID1 profile on two disks. The stack trace has the following signature: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ end trace 0000000000000000 ]--- The 1st line is the most interesting here: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile When a RAID1 block-group is created and a write pointer mismatch between the disks in the RAID set is detected, btrfs sets the alloc_offset to the length of the block group marking it as full. Afterwards the code expects that a balance operation will evacuate the data in this block-group and repair the problems. But before this is possible, the new space of this block-group will be accounted in the free space cache. But in __btrfs_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37977", "url": "https://ubuntu.com/security/CVE-2025-37977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: exynos: Disable iocc if dma-coherent property isn't set If dma-coherent property isn't set then descriptors are non-cacheable and the iocc shareability bits should be disabled. Without this UFS can end up in an incompatible configuration and suffer from random cache related stability issues.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37944", "url": "https://ubuntu.com/security/CVE-2025-37944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry to fetch the next entry from the destination ring. This is incorrect because ath12k_hal_srng_src_get_next_entry is intended for source rings, not destination rings. This leads to invalid entry fetches, causing potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source ring and destination ring have different handling mechanisms and using the wrong function results in incorrect pointer arithmetic and ring management. To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry with ath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensures that the correct function is used for fetching entries from the destination ring, preventing invalid memory accesses. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37761", "url": "https://ubuntu.com/security/CVE-2025-37761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix an out-of-bounds shift when invalidating TLB When the size of the range invalidated is larger than rounddown_pow_of_two(ULONG_MAX), The function macro roundup_pow_of_two(length) will hit an out-of-bounds shift [1]. Use a full TLB invalidation for such cases. v2: - Use a define for the range size limit over which we use a full TLB invalidation. (Lucas) - Use a better calculation of the limit. [1]: [ 39.202421] ------------[ cut here ]------------ [ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10 [ 39.202690] Tainted: [U]=USER [ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 39.202691] Call Trace: [ 39.202692] [ 39.202695] dump_stack_lvl+0x6e/0xa0 [ 39.202699] ubsan_epilogue+0x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe] [ 39.202800] ? find_held_lock+0x2b/0x80 [ 39.202803] ? mark_held_locks+0x40/0x70 [ 39.202806] xe_svm_invalidate+0x459/0x700 [xe] [ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm] [ 39.202900] __mmu_notifier_release+0x1f5/0x270 [ 39.202905] exit_mmap+0x40e/0x450 [ 39.202912] __mmput+0x45/0x110 [ 39.202914] exit_mm+0xc5/0x130 [ 39.202916] do_exit+0x21c/0x500 [ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190 [ 39.202920] do_group_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290 [ 39.202932] do_syscall_64+0xa1/0x180 [ 39.202934] ? do_user_addr_fault+0x59f/0x8a0 [ 39.202937] ? lock_release+0xd2/0x2a0 [ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0 [ 39.202942] ? trace_hardirqs_off+0x4b/0xc0 [ 39.202944] ? clear_bhb_loop+0x25/0x80 [ 39.202946] ? clear_bhb_loop+0x25/0x80 [ 39.202947] ? clear_bhb_loop+0x25/0x80 [ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 39.202952] RIP: 0033:0x7fa945e543e1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293 [ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3 [ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff [ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0 [ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000 [ 39.202970] [ 39.202970] ---[ end trace ]--- (cherry picked from commit b88f48f86500bc0b44b4f73ac66d500a40d320ad)", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37763", "url": "https://ubuntu.com/security/CVE-2025-37763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: take paired job reference For paired jobs, have the fragment job take a reference on the geometry job, so that the geometry job cannot be freed until the fragment job has finished with it. The geometry job structure is accessed when the fragment job is being prepared by the GPU scheduler. Taking the reference prevents the geometry job being freed until the fragment job no longer requires it. Fixes a use after free bug detected by KASAN: [ 124.256386] BUG: KASAN: slab-use-after-free in pvr_queue_prepare_job+0x108/0x868 [powervr] [ 124.264893] Read of size 1 at addr ffff0000084cb960 by task kworker/u16:4/63", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37764", "url": "https://ubuntu.com/security/CVE-2025-37764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix firmware memory leaks Free the memory used to hold the results of firmware image processing when the module is unloaded. Fix the related issue of the same memory being leaked if processing of the firmware image fails during module load. Ensure all firmware GEM objects are destroyed if firmware image processing fails. Fixes memory leaks on powervr module unload detected by Kmemleak: unreferenced object 0xffff000042e20000 (size 94208): comm \"modprobe\", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE. d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H. backtrace (crc dd329dec): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xaa4/0x1f50 [powervr] unreferenced object 0xffff000042d20000 (size 20480): comm \"modprobe\", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................ 00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................ backtrace (crc 395b02e3): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xb0c/0x1f50 [powervr]", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37869", "url": "https://ubuntu.com/security/CVE-2025-37869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37978", "url": "https://ubuntu.com/security/CVE-2025-37978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: integrity: Do not call set_page_dirty_lock() Placing multiple protection information buffers inside the same page can lead to oopses because set_page_dirty_lock() can't be called from interrupt context. Since a protection information buffer is not backed by a file there is no point in setting its page dirty, there is nothing to synchronize. Drop the call to set_page_dirty_lock() and remove the last argument to bio_integrity_unpin_bvec().", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37975", "url": "https://ubuntu.com/security/CVE-2025-37975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: module: Fix out-of-bounds relocation access The current code allows rel[j] to access one element past the end of the relocation section. Simplify to num_relocations which is equivalent to the existing size expression.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37872", "url": "https://ubuntu.com/security/CVE-2025-37872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix memory leak in txgbe_probe() error path When txgbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in txgbe_probe() function, the subsequent error paths after txgbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when txgbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init().", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37873", "url": "https://ubuntu.com/security/CVE-2025-37873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: fix missing ring index trim on error path Commit under Fixes converted tx_prod to be free running but missed masking it on the Tx error path. This crashes on error conditions, for example when DMA mapping fails.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-22120", "url": "https://ubuntu.com/security/CVE-2025-22120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: goto right label 'out_mmap_sem' in ext4_setattr() Otherwise, if ext4_inode_attach_jinode() fails, a hung task will happen because filemap_invalidate_unlock() isn't called to unlock mapping->invalidate_lock. Like this: EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory INFO: task fsstress:374 blocked for more than 122 seconds. Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:fsstress state:D stack:0 pid:374 tgid:374 ppid:373 task_flags:0x440140 flags:0x00000000 Call Trace: __schedule+0x2c9/0x7f0 schedule+0x27/0xa0 schedule_preempt_disabled+0x15/0x30 rwsem_down_read_slowpath+0x278/0x4c0 down_read+0x59/0xb0 page_cache_ra_unbounded+0x65/0x1b0 filemap_get_pages+0x124/0x3e0 filemap_read+0x114/0x3d0 vfs_read+0x297/0x360 ksys_read+0x6c/0xe0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-37799", "url": "https://ubuntu.com/security/CVE-2025-37799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp vmxnet3 driver's XDP handling is buggy for packet sizes using ring0 (that is, packet sizes between 128 - 3k bytes). We noticed MTU-related connectivity issues with Cilium's service load- balancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP backend service where the XDP LB was doing IPIP encap led to overly large packet sizes but only for *some* of the packets (e.g. HTTP GET request) while others (e.g. the prior TCP 3WHS) looked completely fine on the wire. In fact, the pcap recording on the backend node actually revealed that the node with the XDP LB was leaking uninitialized kernel data onto the wire for the affected packets, for example, while the packets should have been 152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes was padded with whatever other data was in that page at the time (e.g. we saw user/payload data from prior processed packets). We only noticed this through an MTU issue, e.g. when the XDP LB node and the backend node both had the same MTU (e.g. 1500) then the curl request got dropped on the backend node's NIC given the packet was too large even though the IPIP-encapped packet normally would never even come close to the MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let the curl request succeed (which also indicates that the kernel ignored the padding, and thus the issue wasn't very user-visible). Commit e127ce7699c1 (\"vmxnet3: Fix missing reserved tailroom\") was too eager to also switch xdp_prepare_buff() from rcd->len to rbi->len. It really needs to stick to rcd->len which is the actual packet length from the descriptor. The latter we also feed into vmxnet3_process_xdp_small(), by the way, and it indicates the correct length needed to initialize the xdp->{data,data_end} parts. For e127ce7699c1 (\"vmxnet3: Fix missing reserved tailroom\") the relevant part was adapting xdp_init_buff() to address the warning given the xdp_data_hard_end() depends on xdp->frame_sz. With that fixed, traffic on the wire looks good again.", "cve_priority": "medium", "cve_public_date": "2025-05-03 12:15:00 UTC" }, { "cve": "CVE-2025-37800", "url": "https://ubuntu.com/security/CVE-2025-37800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential NULL pointer dereference in dev_uevent() If userspace reads \"uevent\" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it. Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing.", "cve_priority": "low", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37878", "url": "https://ubuntu.com/security/CVE-2025-37878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init Move the get_ctx(child_ctx) call and the child_event->ctx assignment to occur immediately after the child event is allocated. Ensure that child_event->ctx is non-NULL before any subsequent error path within inherit_event calls free_event(), satisfying the assumptions of the cleanup code. Details: There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression. The code initially incremented refcount then assigned context immediately after the child_event was created. Later, an early validity check for child_event was added before the refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was added, assuming event->ctx is valid if the pmu_ctx is valid. The problem is that the WARN_ON_ONCE() could trigger after the initial check passed but before child_event->ctx was assigned, violating its precondition. The solution is to assign child_event->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARN_ON_ONCE(). To resolve it, defer the refcount update and child_event->ctx assignment directly after child_event->pmu_ctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmu_ctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in child_ctx to find_get_pmu_context before its refcount/assignment. [ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37803", "url": "https://ubuntu.com/security/CVE-2025-37803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udmabuf: fix a buf size overflow issue during udmabuf creation by casting size_limit_mb to u64 when calculate pglimit.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37879", "url": "https://ubuntu.com/security/CVE-2025-37879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p/net: fix improper handling of bogus negative read/write replies In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37983", "url": "https://ubuntu.com/security/CVE-2025-37983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qibfs: fix _another_ leak failure to allocate inode => leaked dentry... this one had been there since the initial merge; to be fair, if we are that far OOM, the odds of failing at that particular allocation are low...", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37881", "url": "https://ubuntu.com/security/CVE-2025-37881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 (\"ice: Fix some null pointer dereference issues in ice_ptp.c\"). This issue is found by our static analysis tool", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37805", "url": "https://ubuntu.com/security/CVE-2025-37805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound/virtio: Fix cancel_sync warnings on uninitialized work_structs Betty reported hitting the following warning: [ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc [ 8.713570][ T221] cancel_work_sync+0x24/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390 [ 8.714139][ T221] really_probe+0x1bc/0x4c8 ... It seems we're hitting the error path in virtsnd_probe(), which triggers a virtsnd_remove() which iterates over the substreams calling cancel_work_sync() on the elapsed_period work_struct. Looking at the code, from earlier in: virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg() We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsnd_ctl_query_info() fails, we will exit without having initialized the elapsed_period work_struct. When that error path unwinds we then call virtsnd_remove() which as long as the substreams array is allocated, will iterate through calling cancel_work_sync() on the uninitialized work struct hitting this warning. Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data. Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing. Feedback or thoughts would be appreciated!", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37883", "url": "https://ubuntu.com/security/CVE-2025-37883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Add check for get_zeroed_page() Add check for the return value of get_zeroed_page() in sclp_console_init() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37884", "url": "https://ubuntu.com/security/CVE-2025-37884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix deadlock between rcu_tasks_trace and event_mutex. Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegate trace_set_clr_event() to workqueue to avoid such lock dependency.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37808", "url": "https://ubuntu.com/security/CVE-2025-37808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: null - Use spin lock instead of mutex As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37985", "url": "https://ubuntu.com/security/CVE-2025-37985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: wdm: close race between wdm_open and wdm_wwan_port_stop Clearing WDM_WWAN_IN_USE must be the last action or we can open a chardev whose URBs are still poisoned", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37810", "url": "https://ubuntu.com/security/CVE-2025-37810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: check that event count does not exceed event buffer length The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37811", "url": "https://ubuntu.com/security/CVE-2025-37811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: ci_hdrc_imx: fix usbmisc handling usbmisc is an optional device property so it is totally valid for the corresponding data->usbmisc_data to have a NULL value. Check that before dereferencing the pointer. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37812", "url": "https://ubuntu.com/security/CVE-2025-37812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: Fix deadlock when using NCM gadget The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 (\"usb: cdnsp: Fix deadlock issue during using NCM gadget\"). Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using \"iperf --bidir\" over NCM ethernet link. The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37813", "url": "https://ubuntu.com/security/CVE-2025-37813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix invalid pointer dereference in Etron workaround This check is performed before prepare_transfer() and prepare_ring(), so enqueue can already point at the final link TRB of a segment. And indeed it will, some 0.4% of times this code is called. Then enqueue + 1 is an invalid pointer. It will crash the kernel right away or load some junk which may look like a link TRB and cause the real link TRB to be replaced with a NOOP. This wouldn't end well. Use a functionally equivalent test which doesn't dereference the pointer and always gives correct result. Something has crashed my machine twice in recent days while playing with an Etron HC, and a control transfer stress test ran for confirmation has just crashed it again. The same test passes with this patch applied.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37815", "url": "https://ubuntu.com/security/CVE-2025-37815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration Resolve kernel panic while accessing IRQ handler associated with the generated IRQ. This is done by acquiring the spinlock and storing the current interrupt state before handling the interrupt request using generic_handle_irq. A previous fix patch was submitted where 'generic_handle_irq' was replaced with 'handle_nested_irq'. However, this change also causes the kernel panic where after determining which GPIO triggered the interrupt and attempting to call handle_nested_irq with the mapped IRQ number, leads to a failure in locating the registered handler.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37885", "url": "https://ubuntu.com/security/CVE-2025-37885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn't postable Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.", "cve_priority": "low", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37817", "url": "https://ubuntu.com/security/CVE-2025-37817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mcb: fix a double free bug in chameleon_parse_gdd() In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev' would be released in mcb_device_register() via put_device(). Thus, goto 'err' label and free 'mdev' again causes a double free. Just return if mcb_device_register() fails.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37819", "url": "https://ubuntu.com/security/CVE-2025-37819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode() With ACPI in place, gicv2m_get_fwnode() is registered with the pci subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 This is easily reproducible on a Juno board with ACPI boot. Retain the function for later use.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37820", "url": "https://ubuntu.com/security/CVE-2025-37820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen-netfront: handle NULL returned by xdp_convert_buff_to_frame() The function xdp_convert_buff_to_frame() may return NULL if it fails to correctly convert the XDP buffer into an XDP frame due to memory constraints, internal errors, or invalid data. Failing to check for NULL may lead to a NULL pointer dereference if the result is used later in processing, potentially causing crashes, data corruption, or undefined behavior. On XDP redirect failure, the associated page must be released explicitly if it was previously retained via get_page(). Failing to do so may result in a memory leak, as the pages reference count is not decremented.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37886", "url": "https://ubuntu.com/security/CVE-2025-37886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: make wait_context part of q_info Make the wait_context a full part of the q_info struct rather than a stack variable that goes away after pdsc_adminq_post() is done so that the context is still available after the wait loop has given up. There was a case where a slow development firmware caused the adminq request to time out, but then later the FW finally finished the request and sent the interrupt. The handler tried to complete_all() the completion context that had been created on the stack in pdsc_adminq_post() but no longer existed. This caused bad pointer usage, kernel crashes, and much wailing and gnashing of teeth.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37887", "url": "https://ubuntu.com/security/CVE-2025-37887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the \"devlink dev info\" devlink command. This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array. Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37823", "url": "https://ubuntu.com/security/CVE-2025-37823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37988", "url": "https://ubuntu.com/security/CVE-2025-37988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount() Normally do_lock_mount(path, _) is locking a mountpoint pinned by *path and at the time when matching unlock_mount() unlocks that location it is still pinned by the same thing. Unfortunately, for 'beneath' case it's no longer that simple - the object being locked is not the one *path points to. It's the mountpoint of path->mnt. The thing is, without sufficient locking ->mnt_parent may change under us and none of the locks are held at that point. The rules are \t* mount_lock stabilizes m->mnt_parent for any mount m. \t* namespace_sem stabilizes m->mnt_parent, provided that m is mounted. \t* if either of the above holds and refcount of m is positive, we are guaranteed the same for refcount of m->mnt_parent. namespace_sem nests inside inode_lock(), so do_lock_mount() has to take inode_lock() before grabbing namespace_sem. It does recheck that path->mnt is still mounted in the same place after getting namespace_sem, and it does take care to pin the dentry. It is needed, since otherwise we might end up with racing mount --move (or umount) happening while we were getting locks; in that case dentry would no longer be a mountpoint and could've been evicted on memory pressure along with its inode - not something you want when grabbing lock on that inode. However, pinning a dentry is not enough - the matching mount is also pinned only by the fact that path->mnt is mounted on top it and at that point we are not holding any locks whatsoever, so the same kind of races could end up with all references to that mount gone just as we are about to enter inode_lock(). If that happens, we are left with filesystem being shut down while we are holding a dentry reference on it; results are not pretty. What we need to do is grab both dentry and mount at the same time; that makes inode_lock() safe *and* avoids the problem with fs getting shut down under us. After taking namespace_sem we verify that path->mnt is still mounted (which stabilizes its ->mnt_parent) and check that it's still mounted at the same place. From that point on to the matching namespace_unlock() we are guaranteed that mount/dentry pair we'd grabbed are also pinned by being the mountpoint of path->mnt, so we can quietly drop both the dentry reference (as the current code does) and mnt one - it's OK to do under namespace_sem, since we are not dropping the final refs. That solves the problem on do_lock_mount() side; unlock_mount() also has one, since dentry is guaranteed to stay pinned only until the namespace_unlock(). That's easy to fix - just have inode_unlock() done earlier, while it's still pinned by mp->m_dentry.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37824", "url": "https://ubuntu.com/security/CVE-2025-37824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL pointer dereference in tipc_mon_reinit_self() syzbot reported: tipc: Node number set to 1055423674 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 There is a racing condition between workqueue created when enabling bearer and another thread created when disabling bearer right after that as follow: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37989", "url": "https://ubuntu.com/security/CVE-2025-37989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: leds: fix memory leak A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code. The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound. This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer. Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path.", "cve_priority": "medium", "cve_public_date": "2025-05-20 18:15:00 UTC" }, { "cve": "CVE-2025-37828", "url": "https://ubuntu.com/security/CVE-2025-37828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort() A race can occur between the MCQ completion path and the abort handler: once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash. Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed. This is similar to the fix in commit 74736103fb41 (\"scsi: ufs: core: Fix ufshcd_abort_one racing issue\"). This is found by our static analysis tool KNighter.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37829", "url": "https://ubuntu.com/security/CVE-2025-37829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37830", "url": "https://ubuntu.com/security/CVE-2025-37830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scmi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37831", "url": "https://ubuntu.com/security/CVE-2025-37831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. apple_soc_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-37938", "url": "https://ubuntu.com/security/CVE-2025-37938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Verify event formats that have \"%*p..\" The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory. The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses \"%*p..\" the verifier will ignore it, and that could be dangerous. Cover this case as well. Also add to the sample code a use case of \"%*pbl\".", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-39989", "url": "https://ubuntu.com/security/CVE-2025-39989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mce: use is_copy_from_user() to determine copy-from-user context Patch series \"mm/hwpoison: Fix regressions in memory failure handling\", v4. ## 1. What am I trying to do: This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space ## 2. What is the expected outcome and why - For copyin case: Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space. - For instr case: If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage. ## 3. What actually happens and why - For copyin case: kernel panic since v5.17 Commit 4c132d1d844a (\"x86/futex: Remove .fixup usage\") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user(). - For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. ### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a \"real\" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A. Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison). ## Why user process is killed for instr case Commit 046545a661af (\"mm/hwpoison: fix error page recovered but reported \"not ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-22026", "url": "https://ubuntu.com/security/CVE-2025-22026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-37836", "url": "https://ubuntu.com/security/CVE-2025-37836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix reference leak in pci_register_host_bridge() If device_register() fails, call put_device() to give up the reference to avoid a memory leak, per the comment at device_register(). Found by code review. [bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37846", "url": "https://ubuntu.com/security/CVE-2025-37846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: mops: Do not dereference src reg for a set operation The source register is not used for SET* and reading it can result in a UBSAN out-of-bounds array access error, specifically when the MOPS exception is taken from a SET* sequence with XZR (reg 31) as the source. Architecturally this is the only case where a src/dst/size field in the ESR can be reported as 31. Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the use of pt_regs_read_reg() prevented the out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37942", "url": "https://ubuntu.com/security/CVE-2025-37942", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37856", "url": "https://ubuntu.com/security/CVE-2025-37856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: harden block_group::bg_list against list_del() races As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly. However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry. Otherwise we risk the following interleaving (bg_list refcount in parens) T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1) list_del_init(&bg->bg_list); (1) list_move_tail (1) btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1) Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37861", "url": "https://ubuntu.com/security/CVE-2025-37861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37744", "url": "https://ubuntu.com/security/CVE-2025-37744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix memory leak in ath12k_pci_remove() Kmemleak reported this error: unreferenced object 0xffff1c165cec3060 (size 32): comm \"insmod\", pid 560, jiffies 4296964570 (age 235.596s) backtrace: [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0 [<000000001203b155>] kmalloc_trace+0x40/0x88 [<0000000028adc9c8>] _request_firmware+0xb8/0x608 [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80 [<000000005011a682>] local_pci_probe+0x48/0xd0 [<00000000077cd295>] pci_device_probe+0xb4/0x200 [<0000000087184c94>] really_probe+0x150/0x2c0 The firmware memory was allocated in ath12k_pci_probe(), but not freed in ath12k_pci_remove() in case ATH12K_FLAG_QMI_FAIL bit is set. So call ath12k_fw_unmap() to free the memory. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37745", "url": "https://ubuntu.com/security/CVE-2025-37745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM: hibernate: Avoid deadlock in hibernate_compressor_param_set() syzbot reported a deadlock in lock_system_sleep() (see below). The write operation to \"/sys/module/hibernate/parameters/compressor\" conflicts with the registration of ieee80211 device, resulting in a deadlock when attempting to acquire system_transition_mutex under param_lock. To avoid this deadlock, change hibernate_compressor_param_set() to use mutex_trylock() for attempting to acquire system_transition_mutex and return -EBUSY when it fails. Task flags need not be saved or adjusted before calling mutex_trylock(&system_transition_mutex) because the caller is not going to end up waiting for this mutex and if it runs concurrently with system suspend in progress, it will be frozen properly when it returns to user space. syzbot report: syz-executor895/5833 is trying to acquire lock: ffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, at: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56 but task is already holding lock: ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: kernel_param_lock kernel/params.c:607 [inline] ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: param_attr_store+0xe6/0x300 kernel/params.c:586 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (param_lock){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [inline] rate_control_alloc net/mac80211/rate.c:266 [inline] ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558 init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910 do_one_initcall+0x128/0x700 init/main.c:1257 do_initcall_level init/main.c:1319 [inline] do_initcalls init/main.c:1335 [inline] do_basic_setup init/main.c:1354 [inline] kernel_init_freeable+0x5c7/0x900 init/main.c:1568 kernel_init+0x1c/0x2b0 init/main.c:1457 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #2 (rtnl_mutex){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 wg_pm_notification drivers/net/wireguard/device.c:80 [inline] wg_pm_notification+0x49/0x180 drivers/net/wireguard/device.c:64 notifier_call_chain+0xb7/0x410 kernel/notifier.c:85 notifier_call_chain_robust kernel/notifier.c:120 [inline] blocking_notifier_call_chain_robust kernel/notifier.c:345 [inline] blocking_notifier_call_chain_robust+0xc9/0x170 kernel/notifier.c:333 pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102 snapshot_open+0x189/0x2b0 kernel/power/user.c:77 misc_open+0x35a/0x420 drivers/char/misc.c:179 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x735/0x1c40 fs/open.c:956 vfs_open+0x82/0x3f0 fs/open.c:1086 do_open fs/namei.c:3830 [inline] path_openat+0x1e88/0x2d80 fs/namei.c:3989 do_filp_open+0x20c/0x470 fs/namei.c:4016 do_sys_openat2+0x17a/0x1e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [inline] __do_sys_openat fs/open.c:1459 [inline] __se_sys_openat fs/open.c:1454 [inline] __x64_sys_openat+0x175/0x210 fs/open.c:1454 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #1 ((pm_chain_head).rwsem){++++}-{4:4}: down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 blocking_notifier_call_chain_robust kerne ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37945", "url": "https://ubuntu.com/security/CVE-2025-37945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY DSA has 2 kinds of drivers: 1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz 2. Those who don't: all others. The above methods should be optional. For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on. Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered: \tWARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && \t\tphydev->state != PHY_UP); because the PHY state machine is running. It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user. The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs. mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 (\"phylib: fix PAL state machine restart on resume\"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible. This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming mac_managed_pm is set correctly, a quick search indicates the following other drivers might be affected: $ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/prestera_main.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/altera/altera_tse_main.c drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c drivers/net/ethernet/meta/fbnic/fbnic_phylink.c drivers/net/ethernet/tehuti/tn40_phy.c drivers/net/ethernet/mscc/ocelot_net.c Make the existing conditions dependent on the PHY device having a phydev->phy_link_change() implementation equal to the default phy_link_change() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylink_phy_change() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phy_link_change() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test. Thus, for the situation where the PM is not managed b ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37759", "url": "https://ubuntu.com/security/CVE-2025-37759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: fix handling recovery & reissue in ublk_abort_queue() Commit 8284066946e6 (\"ublk: grab request reference when the request is handled by userspace\") doesn't grab request reference in case of recovery reissue. Then the request can be requeued & re-dispatch & failed when canceling uring command. If it is one zc request, the request can be freed before io_uring returns the zc buffer back, then cause kernel panic: [ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 126.773657] #PF: supervisor read access in kernel mode [ 126.774052] #PF: error_code(0x0000) - not-present page [ 126.774455] PGD 0 P4D 0 [ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI [ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full) [ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 [ 126.776275] Workqueue: iou_exit io_ring_exit_work [ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv] Fixes it by always grabbing request reference for aborting the request.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23140", "url": "https://ubuntu.com/security/CVE-2025-23140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released. However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq(). [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-22126", "url": "https://ubuntu.com/security/CVE-2025-22126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix mddev uaf while iterating all_mddevs list While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex. Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-37765", "url": "https://ubuntu.com/security/CVE-2025-37765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix ttm_bo_delayed_delete oops Fix an oops in ttm_bo_delayed_delete which results from dererencing a dangling pointer: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216 Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024 Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290 Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc FS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 The cause of this is: - drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo. - nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo. - nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete. - ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault. Fix this by moving the drm_prime_gem_destroy call from nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will be run after ttm_bo_delayed_delete.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37766", "url": "https://ubuntu.com/security/CVE-2025-37766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37767", "url": "https://ubuntu.com/security/CVE-2025-37767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37768", "url": "https://ubuntu.com/security/CVE-2025-37768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37769", "url": "https://ubuntu.com/security/CVE-2025-37769", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm/smu11: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE. (cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71)", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37770", "url": "https://ubuntu.com/security/CVE-2025-37770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37771", "url": "https://ubuntu.com/security/CVE-2025-37771", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37772", "url": "https://ubuntu.com/security/CVE-2025-37772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix workqueue crash in cma_netevent_work_handler struct rdma_cm_id has member \"struct work_struct net_work\" that is reused for enqueuing cma_netevent_work_handler()s onto cma_wq. Below crash[1] can occur if more than one call to cma_netevent_callback() occurs in quick succession, which further enqueues cma_netevent_work_handler()s for the same rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cma_netevent_callback() and the 2nd INIT_WORK would overwrite the 1st work item (for the same rdma_cm_id), despite grabbing id_table_lock during enqueue. Also drgn analysis [2] indicates the work item was likely overwritten. Fix this by moving the INIT_WORK() to __rdma_create_id(), so that it doesn't race with any existing queue_work() or its worker thread. [1] Trimmed crash stack: ============================================= BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Call Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 ============================================= [2] drgn crash analysis: >>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9) Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168\tstrscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); >>> trace[8][\"work\"] *(struct work_struct *)0xffff92577d0a21d8 = { \t.data = (atomic_long_t){ \t\t.counter = (s64)536870912, <=== Note \t}, \t.entry = (struct list_head){ \t\t.next = (struct list_head *)0xffff924d075924c0, \t\t.prev = (struct list_head *)0xffff924d075924c0, \t}, \t.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, } Suspicion is that pwq is NULL: >>> trace[8][\"pwq\"] (struct pool_workqueue *) In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work); and get_work_pwq() is: static struct pool_workqueue *get_work_pwq(struct work_struct *work) { \tunsigned long data = atomic_long_read(&work->data); \tif (data & WORK_STRUCT_PWQ) \t\treturn work_struct_pwq(data); \telse \t\treturn NULL; } WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4) But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168\tstrscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37773", "url": "https://ubuntu.com/security/CVE-2025-37773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: add filesystem context source name check In certain scenarios, for example, during fuzz testing, the source name may be NULL, which could lead to a kernel panic. Therefore, an extra check for the source name should be added.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37775", "url": "https://ubuntu.com/security/CVE-2025-37775", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix the warning from __kernel_write_iter [ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280 This patch doesn't allow writing to directory.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37778", "url": "https://ubuntu.com/security/CVE-2025-37778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37863", "url": "https://ubuntu.com/security/CVE-2025-37863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: don't allow datadir only In theory overlayfs could support upper layer directly referring to a data layer, but there's no current use case for this. Originally, when data-only layers were introduced, this wasn't allowed, only introduced by the \"datadir+\" feature, but without actually handling this case, resulting in an Oops. Fix by disallowing datadir without lowerdir.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37780", "url": "https://ubuntu.com/security/CVE-2025-37780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: Prevent the use of too small fid syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1] The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handle. Here, fh_len is used to indirectly confirm that the value of handle_bytes is greater than 3 before accessing parent_block. [1] BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37781", "url": "https://ubuntu.com/security/CVE-2025-37781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: cros-ec-tunnel: defer probe if parent EC is not present When i2c-cros-ec-tunnel and the EC driver are built-in, the EC parent device will not be found, leading to NULL pointer dereference. That can also be reproduced by unbinding the controller driver and then loading i2c-cros-ec-tunnel module (or binding the device). [ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 271.998215] #PF: supervisor read access in kernel mode [ 272.003351] #PF: error_code(0x0000) - not-present page [ 272.008485] PGD 0 P4D 0 [ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI [ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5 [ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC [ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021 [ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel] [ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9 [ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282 [ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000 [ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00 [ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000 [ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000 [ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10 [ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000 [ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0 [ 272.129155] Call Trace: [ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110 [ 272.137985] platform_probe+0x69/0xa0 [ 272.141652] really_probe+0x152/0x310 [ 272.145318] __driver_probe_device+0x77/0x110 [ 272.149678] driver_probe_device+0x1e/0x190 [ 272.153864] __driver_attach+0x10b/0x1e0 [ 272.157790] ? driver_attach+0x20/0x20 [ 272.161542] bus_for_each_dev+0x107/0x150 [ 272.165553] bus_add_driver+0x15d/0x270 [ 272.169392] driver_register+0x65/0x110 [ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698] [ 272.182617] do_one_initcall+0x110/0x350 [ 272.186543] ? security_kernfs_init_security+0x49/0xd0 [ 272.191682] ? __kernfs_new_node+0x1b9/0x240 [ 272.195954] ? security_kernfs_init_security+0x49/0xd0 [ 272.201093] ? __kernfs_new_node+0x1b9/0x240 [ 272.205365] ? kernfs_link_sibling+0x105/0x130 [ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0 [ 272.214773] ? kernfs_activate+0x57/0x70 [ 272.218699] ? kernfs_add_one+0x118/0x160 [ 272.222710] ? __kernfs_create_file+0x71/0xa0 [ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110 [ 272.232033] ? internal_create_group+0x453/0x4a0 [ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0 [ 272.241355] ? __free_frozen_pages+0x1dc/0x420 [ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0 [ 272.250505] ? load_module+0x1509/0x16f0 [ 272.254431] do_init_module+0x60/0x230 [ 272.258181] __se_sys_finit_module+0x27a/0x370 [ 272.262627] do_syscall_64+0x6a/0xf0 [ 272.266206] ? do_syscall_64+0x76/0xf0 [ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90 [ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 272.279887] RIP: 0033:0x7b9309168d39 [ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8 [ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37979", "url": "https://ubuntu.com/security/CVE-2025-37979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix sc7280 lpass potential buffer overflow Case values introduced in commit 5f78e1fb7a3e (\"ASoC: qcom: Add driver support for audioreach solution\") cause out of bounds access in arrays of sc7280 driver data (e.g. in case of RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()). Redefine LPASS_MAX_PORTS to consider the maximum possible port id for q6dsp as sc7280 driver utilizes some of those values. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37784", "url": "https://ubuntu.com/security/CVE-2025-37784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ti: icss-iep: Fix possible NULL pointer dereference for perout request The ICSS IEP driver tracks perout and pps enable state with flags. Currently when disabling pps and perout signals during icss_iep_exit(), results in NULL pointer dereference for perout. To fix the null pointer dereference issue, the icss_iep_perout_enable_hw function can be modified to directly clear the IEP CMP registers when disabling PPS or PEROUT, without referencing the ptp_perout_request structure, as its contents are irrelevant in this case.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37786", "url": "https://ubuntu.com/security/CVE-2025-37786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After \"complete\" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37864", "url": "https://ubuntu.com/security/CVE-2025-37864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as commit b117e1e8a86d (\"net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del\"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack. It seems counter-productive to block that path by implementing shim .ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from running, although we could do that. Accepting that cleanup is necessary seems to be the only option. Especially since we appear to be coming back at this from a different angle as well. Russell King is noticing that the WARN_ON() triggers even for VLANs: https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/ What happens in the bug report above is that dsa_port_do_vlan_del() fails, then the VLAN entry lingers on, and then we warn on unbind and leak it. This is not a straight revert of the blamed commit, but we now add an informational print to the kernel log (to still have a way to see that bugs exist), and some extra comments gathered from past years' experience, to justify the logic.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37865", "url": "https://ubuntu.com/security/CVE-2025-37865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported Russell King reports that on the ZII dev rev B, deleting a bridge VLAN from a user port fails with -ENOENT: https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/ This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(), which tries to find an MST entry in &chip->msts associated with the SID, but fails and returns -ENOENT as such. But we know that this chip does not support MST at all, so that is not surprising. The question is why does the guard in mv88e6xxx_mst_put() not exit early: \tif (!sid) \t\treturn 0; And the answer seems to be simple: the sid comes from vlan.sid which supposedly was previously populated by mv88e6xxx_vtu_get(). But some chip->info->ops->vtu_getnext() implementations do not populate vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case, later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is just residual stack memory. Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge VLAN mapped to the default MSTI. For some chips, SID 0 is valid and installed by mv88e6xxx_stu_setup(). A chip which does not support the STU would implicitly only support mapping all VLANs to the default MSTI, so although SID 0 is not valid, it would be sufficient, if we were to zero-initialize the vlan structure, to fix the bug, due to the coincidence that a test for vlan.sid == 0 already exists and leads to the same (correct) behavior. Another option which would be sufficient would be to add a test for mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one which already exists in mv88e6xxx_mst_get(). But that placement means the caller will have to dereference vlan.sid, which means it will access uninitialized memory, which is not nice even if it ignores it later. So we end up making both modifications, in order to not rely just on the sid == 0 coincidence, but also to avoid having uninitialized structure fields which might get temporarily accessed.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37787", "url": "https://ubuntu.com/security/CVE-2025-37787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registered Russell King reports that a system with mv88e6xxx dereferences a NULL pointer when unbinding this driver: https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/ The crash seems to be in devlink_region_destroy(), which is not NULL tolerant but is given a NULL devlink global region pointer. At least on some chips, some devlink regions are conditionally registered since the blamed commit, see mv88e6xxx_setup_devlink_regions_global(): \t\tif (cond && !cond(chip)) \t\t\tcontinue; These are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chip does not have an STU or PVT, it should crash like this. To fix the issue, avoid unregistering those regions which are NULL, i.e. were skipped at mv88e6xxx_setup_devlink_regions_global() time.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37788", "url": "https://ubuntu.com/security/CVE-2025-37788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path In the for loop used to allocate the loc_array and bmap for each port, a memory leak is possible when the allocation for loc_array succeeds, but the allocation for bmap fails. This is because when the control flow goes to the label free_eth_finfo, only the allocations starting from (i-1)th iteration are freed. Fix that by freeing the loc_array in the bmap allocation error path.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37874", "url": "https://ubuntu.com/security/CVE-2025-37874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix memory leak in ngbe_probe() error path When ngbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent error paths after ngbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when ngbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init().", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37789", "url": "https://ubuntu.com/security/CVE-2025-37789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix nested key length validation in the set() action It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37980", "url": "https://ubuntu.com/security/CVE-2025-37980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix resource leak in blk_register_queue() error path When registering a queue fails after blk_mq_sysfs_register() is successful but the function later encounters an error, we need to clean up the blk_mq_sysfs resources. Add the missing blk_mq_sysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37790", "url": "https://ubuntu.com/security/CVE-2025-37790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Set SOCK_RCU_FREE Bind lookup runs under RCU, so ensure that a socket doesn't go away in the middle of a lookup.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37875", "url": "https://ubuntu.com/security/CVE-2025-37875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igc: fix PTM cycle trigger logic Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction. The issue can be reproduced with the following: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: \"ioctl PTP_OFFSET_PRECISE: Connection timed out\" when the PTM transaction fails This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM. The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle. When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump. With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37792", "url": "https://ubuntu.com/security/CVE-2025-37792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: Prevent potential NULL dereference The btrtl_initialize() function checks that rtl_load_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch: drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37867", "url": "https://ubuntu.com/security/CVE-2025-37867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Silence oversized kvmalloc() warning syzkaller triggered an oversized kvmalloc() warning. Silence it by adding __GFP_NOWARN. syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37793", "url": "https://ubuntu.com/security/CVE-2025-37793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, avs_component_probe() does not check for this case, which results in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37982", "url": "https://ubuntu.com/security/CVE-2025-37982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: fix memory leak in wl1251_tx_work The skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup fails with a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.", "cve_priority": "medium", "cve_public_date": "2025-05-20 17:15:00 UTC" }, { "cve": "CVE-2025-37794", "url": "https://ubuntu.com/security/CVE-2025-37794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Purge vif txq in ieee80211_do_stop() After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point).", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-37796", "url": "https://ubuntu.com/security/CVE-2025-37796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x: fix use after free access in at76_disconnect The memory pointed to by priv is freed at the end of at76_delete_device function (using ieee80211_free_hw). But the code then accesses the udev field of the freed object to put the USB device. This may also lead to a memory leak of the usb device. Fix this by using udev from interface.", "cve_priority": "medium", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-23141", "url": "https://ubuntu.com/security/CVE-2025-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where \"accepting\" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37940", "url": "https://ubuntu.com/security/CVE-2025-37940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add cond_resched() to ftrace_graph_set_hash() When the kernel contains a large number of functions that can be traced, the loop in ftrace_graph_set_hash() may take a lot of time to execute. This may trigger the softlockup watchdog. Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions. This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37844", "url": "https://ubuntu.com/security/CVE-2025-37844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: avoid NULL pointer dereference in dbg call cifs_server_dbg() implies server to be non-NULL so move call under condition to avoid NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23142", "url": "https://ubuntu.com/security/CVE-2025-23142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: detect and prevent references to a freed transport in sendmsg sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent. There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf(). This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read. This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as \"dead\". In order to do this, the patch restores the \"dead\" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e (\"sctp: remove the dead field of sctp_transport\"). Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process. If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send. The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23144", "url": "https://ubuntu.com/security/CVE-2025-23144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable().", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37892", "url": "https://ubuntu.com/security/CVE-2025-37892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: inftlcore: Add error check for inftl_read_oob() In INFTL_findwriteunit(), the return value of inftl_read_oob() need to be checked. A proper implementation can be found in INFTL_deleteblock(). The status will be set as SECTOR_IGNORE to break from the while-loop correctly if the inftl_read_oob() fails.", "cve_priority": "low", "cve_public_date": "2025-05-20 11:15:00 UTC" }, { "cve": "CVE-2025-23145", "url": "https://ubuntu.com/security/CVE-2025-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix NULL pointer in can_accept_new_subflow When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL. Call trace: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons. Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fixes this issue by moving the 'subflow_req->msk' under the `own_req == true` conditional. Note that the !msk check in subflow_hmac_valid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23146", "url": "https://ubuntu.com/security/CVE-2025-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: ene-kb3930: Fix a potential NULL pointer dereference The off_gpios could be NULL. Add missing check in the kb3930_probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f (\"backlight: hx8357: Fix potential NULL pointer dereference\"). This was detected by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37839", "url": "https://ubuntu.com/security/CVE-2025-37839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: remove wrong sb->s_sequence check Journal emptiness is not determined by sb->s_sequence == 0 but rather by sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a valid transaction ID so the check can spuriously trigger. Remove the invalid WARN_ON.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23147", "url": "https://ubuntu.com/security/CVE-2025-23147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: Add NULL pointer check in i3c_master_queue_ibi() The I3C master driver may receive an IBI from a target device that has not been probed yet. In such cases, the master calls `i3c_master_queue_ibi()` to queue an IBI work task, leading to \"Unable to handle kernel read from unreadable memory\" and resulting in a kernel panic. Typical IBI handling flow: 1. The I3C master scans target devices and probes their respective drivers. 2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`. 3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver’s IBI handler task. However, since target device events are asynchronous to the I3C probe sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`, leading to a kernel panic. Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing an uninitialized `dev->ibi`, ensuring stability.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23148", "url": "https://ubuntu.com/security/CVE-2025-23148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe() soc_dev_attr->revision could be NULL, thus, a pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 (\"ice: Fix some null pointer dereference issues in ice_ptp.c\"). This issue is found by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23149", "url": "https://ubuntu.com/security/CVE-2025-23149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: do not start chip while suspended Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can lead to a spurious tpm_chip_start() call: [35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] [35985.503863] ? __warn+0xd4/0x260 [35985.503868] ? __i2c_transfer+0xbe/0x810 [35985.503874] ? report_bug+0xf3/0x210 [35985.503882] ? handle_bug+0x63/0xb0 [35985.503887] ? exc_invalid_op+0x16/0x50 [35985.503892] ? asm_exc_invalid_op+0x16/0x20 [35985.503904] ? __i2c_transfer+0xbe/0x810 [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0 [35985.503920] tpm_cr50_i2c_read+0x8e/0x120 [35985.503928] tpm_cr50_request_locality+0x75/0x170 [35985.503935] tpm_chip_start+0x116/0x160 [35985.503942] tpm_try_get_ops+0x57/0x90 [35985.503948] tpm_find_get_ops+0x26/0xd0 [35985.503955] tpm_get_random+0x2d/0x80 Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in such a failure case.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23150", "url": "https://ubuntu.com/security/CVE-2025-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one error in do_split Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split. BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The following loop is located right above 'if' statement. for (i = count-1; i >= 0; i--) { \t/* is more than half of this entry in 2nd half of the block? */ \tif (size + map[i].size/2 > blocksize/2) \t\tbreak; \tsize += map[i].size; \tmove++; } 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23151", "url": "https://ubuntu.com/security/CVE-2025-23151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Fix race between unprepare and queue_buf A client driver may use mhi_unprepare_from_transfer() to quiesce incoming data during the client driver's tear down. The client driver might also be processing data at the same time, resulting in a call to mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs after mhi_unprepare_from_transfer() has torn down the channel, a panic will occur due to an invalid dereference leading to a page fault. This occurs because mhi_gen_tre() does not verify the channel state after locking it. Fix this by having mhi_gen_tre() confirm the channel state is valid, or return error to avoid accessing deinitialized data. [mani: added stable tag]", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23156", "url": "https://ubuntu.com/security/CVE-2025-23156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi_parser: refactor hfi packet parsing logic words_count denotes the number of words in total payload, while data points to payload of various property within it. When words_count reaches last word, data can access memory beyond the total payload. This can lead to OOB access. With this patch, the utility api for handling individual properties now returns the size of data consumed. Accordingly remaining bytes are calculated before parsing the payload, thereby eliminates the OOB access possibilities.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23157", "url": "https://ubuntu.com/security/CVE-2025-23157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi_parser: add check to avoid out of bound access There is a possibility that init_codecs is invoked multiple times during manipulated payload from video firmware. In such case, if codecs_count can get incremented to value more than MAX_CODEC_NUM, there can be OOB access. Reset the count so that it always starts from beginning.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37840", "url": "https://ubuntu.com/security/CVE-2025-37840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: brcmnand: fix PM resume warning Fixed warning on PM resume as shown below caused due to uninitialized struct nand_operation that checks chip select field : WARN_ON(op->cs >= nanddev_ntargets(&chip->base) [ 14.588522] ------------[ cut here ]------------ [ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8 [ 14.588553] Modules linked in: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16 [ 14.588590] Tainted: [W]=WARN [ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree) [ 14.588598] Call trace: [ 14.588604] dump_backtrace from show_stack+0x18/0x1c [ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c [ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c [ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c [ 14.588653] r5:c08d40b0 r4:c1003cb0 [ 14.588656] dump_stack from __warn+0x84/0xe4 [ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194 [ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000 [ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8 [ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048 [ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150 [ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040 [ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54 [ 14.588735] r5:00000010 r4:c0840a50 [ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c [ 14.588757] dpm_run_callback from device_resume+0xc0/0x324 [ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010 [ 14.588779] device_resume from dpm_resume+0x130/0x160 [ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0 [ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20 [ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414 [ 14.588826] r4:00000010 [ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8 [ 14.588848] r5:c228a414 r4:00000000 [ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc [ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000 [ 14.588871] r4:00000003 [ 14.588874] pm_suspend from state_store+0x74/0xd0 [ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003 [ 14.588892] state_store from kobj_attr_store+0x1c/0x28 [ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250 [ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c [ 14.588936] r5:c3502900 r4:c0d92a48 [ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0 [ 14.588956] r5:c3502900 r4:c3501f40 [ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420 [ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00 [ 14.588983] r4:c042a88c [ 14.588987] vfs_write from ksys_write+0x74/0xe4 [ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00 [ 14.589008] r4:c34f7f00 [ 14.589011] ksys_write from sys_write+0x10/0x14 [ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004 [ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c [ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0) [ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001 [ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78 [ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8 [ 14.589065] ---[ end trace 0000000000000000 ]--- The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, when doing PM resume operation in compliance with the controller support for single die nand chip. Switching from nand_reset_op() to nan ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37849", "url": "https://ubuntu.com/security/CVE-2025-37849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.", "cve_priority": "high", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23158", "url": "https://ubuntu.com/security/CVE-2025-23158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: add check to handle incorrect queue size qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23159", "url": "https://ubuntu.com/security/CVE-2025-23159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: add a check to handle OOB in sfr region sfr->buf_size is in shared memory and can be modified by malicious user. OOB write is possible when the size is made higher than actual sfr data buffer. Cap the size to allocated size for such cases.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-23160", "url": "https://ubuntu.com/security/CVE-2025-23160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37850", "url": "https://ubuntu.com/security/CVE-2025-37850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config() With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line: \tdo_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm])); due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero. This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero. Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section [ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37851", "url": "https://ubuntu.com/security/CVE-2025-37851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: Add 'plane' value check Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB of the enum parameter plane. The value of this parameter is initialized in dss_init_overlays and in the current state of the code it cannot take this value so it's not a real problem. For the purposes of defensive coding it wouldn't be superfluous to check the parameter value, because some functions down the call stack process this value correctly and some not. For example, in dispc_ovl_setup_global_alpha it may lead to buffer overflow. Add check for this value. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23161", "url": "https://ubuntu.com/security/CVE-2025-23161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type The access to the PCI config space via pci_ops::read and pci_ops::write is a low-level hardware access. The functions can be accessed with disabled interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this purpose. A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in the same context as the pci_lock. Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with interrupts disabled. This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90 [bigeasy: reword commit message] Tested-off-by: Luis Claudio R. Goncalves [kwilczynski: commit log] [bhelgaas: add back report info from https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37852", "url": "https://ubuntu.com/security/CVE-2025-37852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() Add error handling to propagate amdgpu_cgs_create_device() failures to the caller. When amdgpu_cgs_create_device() fails, release hwmgr and return -ENOMEM to prevent null pointer dereference. [v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37853", "url": "https://ubuntu.com/security/CVE-2025-37853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: debugfs hang_hws skip GPU with MES debugfs hang_hws is used by GPU reset test with HWS, for MES this crash the kernel with NULL pointer access because dqm->packet_mgr is not setup for MES path. Skip GPU with MES for now, MES hang_hws debugfs interface will be supported later.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37854", "url": "https://ubuntu.com/security/CVE-2025-37854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix mode1 reset crash issue If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM. There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash. To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-23163", "url": "https://ubuntu.com/security/CVE-2025-23163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vlan: don't propagate flags on open With the device instance lock, there is now a possibility of a deadlock: [ 1.211455] ============================================ [ 1.211571] WARNING: possible recursive locking detected [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted [ 1.211823] -------------------------------------------- [ 1.211936] ip/184 is trying to acquire lock: [ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0 [ 1.212207] [ 1.212207] but task is already holding lock: [ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.212487] [ 1.212487] other info that might help us debug this: [ 1.212626] Possible unsafe locking scenario: [ 1.212626] [ 1.212751] CPU0 [ 1.212815] ---- [ 1.212871] lock(&dev->lock); [ 1.212944] lock(&dev->lock); [ 1.213016] [ 1.213016] *** DEADLOCK *** [ 1.213016] [ 1.213143] May be due to missing lock nesting notation [ 1.213143] [ 1.213294] 3 locks held by ip/184: [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0 [ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0 [ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.213895] [ 1.213895] stack backtrace: [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 1.213994] Call Trace: [ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0 [ 1.214000] print_deadlock_bug+0x28b/0x2a0 [ 1.214020] lock_acquire+0xea/0x2a0 [ 1.214027] __mutex_lock+0xbf/0xd40 [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev [ 1.214042] __dev_open+0x145/0x270 [ 1.214046] __dev_change_flags+0xb0/0x1e0 [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0 [ 1.214058] notifier_call_chain+0x78/0x120 [ 1.214062] netif_open+0x6d/0x90 [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0 [ 1.214066] bond_enslave+0x64c/0x1230 [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0 [ 1.214077] do_setlink+0x516/0x13b0 [ 1.214094] rtnl_newlink+0xaba/0xb80 [ 1.214132] rtnetlink_rcv_msg+0x440/0x490 [ 1.214144] netlink_rcv_skb+0xeb/0x120 [ 1.214150] netlink_unicast+0x1f9/0x320 [ 1.214153] netlink_sendmsg+0x346/0x3f0 [ 1.214157] __sock_sendmsg+0x86/0xb0 [ 1.214160] ____sys_sendmsg+0x1c8/0x220 [ 1.214164] ___sys_sendmsg+0x28f/0x2d0 [ 1.214179] __x64_sys_sendmsg+0xef/0x140 [ 1.214184] do_syscall_64+0xec/0x1d0 [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 1.214191] RIP: 0033:0x7f2d1b4a7e56 Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down) When we enslave the lower device (netdevsim0) which has a vlan, we propagate vlan's allmuti/promisc flags during ndo_open. This causes (re)locking on of the real_dev. Propagate allmulti/promisc on flags change, not on the open. There is a slight semantics change that vlans that are down now propagate the flags, but this seems unlikely to result in the real issues. Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37857", "url": "https://ubuntu.com/security/CVE-2025-37857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix array overflow in st_setup() Change the array size to follow parms size instead of a fixed value.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37738", "url": "https://ubuntu.com/security/CVE-2025-37738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: ignore xattrs past end Once inside 'ext4_xattr_inode_dec_ref_all' we should ignore xattrs entries past the 'end' entry. This fixes the following KASAN reported issue: ================================================================== BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 Read of size 4 at addr ffff888012c120c4 by task repro/2065 CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x1fd/0x300 ? tcp_gro_dev_warn+0x260/0x260 ? _printk+0xc0/0x100 ? read_lock_is_recursive+0x10/0x10 ? irq_work_queue+0x72/0xf0 ? __virt_addr_valid+0x17b/0x4b0 print_address_description+0x78/0x390 print_report+0x107/0x1f0 ? __virt_addr_valid+0x17b/0x4b0 ? __virt_addr_valid+0x3ff/0x4b0 ? __phys_addr+0xb5/0x160 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 kasan_report+0xcc/0x100 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ? ext4_xattr_delete_inode+0xd30/0xd30 ? __ext4_journal_ensure_credits+0x5f0/0x5f0 ? __ext4_journal_ensure_credits+0x2b/0x5f0 ? inode_update_timestamps+0x410/0x410 ext4_xattr_delete_inode+0xb64/0xd30 ? ext4_truncate+0xb70/0xdc0 ? ext4_expand_extra_isize_ea+0x1d20/0x1d20 ? __ext4_mark_inode_dirty+0x670/0x670 ? ext4_journal_check_start+0x16f/0x240 ? ext4_inode_is_fast_symlink+0x2f2/0x3a0 ext4_evict_inode+0xc8c/0xff0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 ? do_raw_spin_unlock+0x53/0x8a0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 evict+0x4ac/0x950 ? proc_nr_inodes+0x310/0x310 ? trace_ext4_drop_inode+0xa2/0x220 ? _raw_spin_unlock+0x1a/0x30 ? iput+0x4cb/0x7e0 do_unlinkat+0x495/0x7c0 ? try_break_deleg+0x120/0x120 ? 0xffffffff81000000 ? __check_object_size+0x15a/0x210 ? strncpy_from_user+0x13e/0x250 ? getname_flags+0x1dc/0x530 __x64_sys_unlinkat+0xc8/0xf0 do_syscall_64+0x65/0x110 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x434ffd Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8 RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107 RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001 The buggy address belongs to the object at ffff888012c12000 which belongs to the cache filp of size 360 The buggy address is located 196 bytes inside of freed 360-byte region [ffff888012c12000, ffff888012c12168) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12 head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x40(head|node=0|zone=0) page_type: f5(slab) raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000 head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888012c12180: fc fc fc fc fc fc fc fc fc ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37739", "url": "https://ubuntu.com/security/CVE-2025-37739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks() syzbot reports an UBSAN issue as below: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10 index 18446744073709550692 is out of range for type '__le32[5]' (aka 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [inline] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [inline] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f238798cde9 index 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long) In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to access .i_nid[-924], it means both offset[0] and level should zero. The possible case should be in f2fs_do_truncate_blocks(), we try to truncate inode size to zero, however, dn.ofs_in_node is zero and dn.node_page is not an inode page, so it fails to truncate inode page, and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result in this issue. \tif (dn.ofs_in_node || IS_INODE(dn.node_page)) { \t\tf2fs_truncate_data_blocks_range(&dn, count); \t\tfree_from += count; \t} I guess the reason why dn.node_page is not an inode page could be: there are multiple nat entries share the same node block address, once the node block address was reused, f2fs_get_node_page() may load a non-inode block. Let's add a sanity check for such condition to avoid out-of-bounds access issue.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37943", "url": "https://ubuntu.com/security/CVE-2025-37943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath12k_dp_rx_h_undecap_nwifi function for DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially resulting in invalid data access and memory corruption. Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37740", "url": "https://ubuntu.com/security/CVE-2025-37740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add sanity check for agwidth in dbMount The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG. To avoid this issue, add a check for agwidth in dbAllocAG.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37741", "url": "https://ubuntu.com/security/CVE-2025-37741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Prevent copying of nlink with value 0 from disk inode syzbot report a deadlock in diFree. [1] When calling \"ioctl$LOOP_SET_STATUS64\", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated. When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree(). To avoid this, first check the nlink value of dinode before setting iag inode. [1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted -------------------------------------------- syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index])); *** DEADLOCK *** May be due to missing lock nesting notation 5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669 stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37858", "url": "https://ubuntu.com/security/CVE-2025-37858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Prevent integer overflow in AG size calculation The JFS filesystem calculates allocation group (AG) size using 1 << l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB aggregates on 32-bit systems), this 32-bit shift operation causes undefined behavior and improper AG sizing. On 32-bit architectures: - Left-shifting 1 by 32+ bits results in 0 due to integer overflow - This creates invalid AG sizes (0 or garbage values) in sbi->bmap->db_agsize - Subsequent block allocations would reference invalid AG structures - Could lead to: - Filesystem corruption during extend operations - Kernel crashes due to invalid memory accesses - Security vulnerabilities via malformed on-disk structures Fix by casting to s64 before shifting: bmp->db_agsize = (s64)1 << l2agsize; This ensures 64-bit arithmetic even on 32-bit architectures. The cast matches the data type of db_agsize (s64) and follows similar patterns in JFS block calculation code. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37742", "url": "https://ubuntu.com/security/CVE-2025-37742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of imap allocated in the diMount() function syzbot reports that hex_dump_to_buffer is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276 diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876 jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156 evict+0x723/0xd10 fs/inode.c:796 iput_final fs/inode.c:1946 [inline] iput+0x97b/0xdb0 fs/inode.c:1972 txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733 kthread+0x6b9/0xef0 kernel/kthread.c:464 ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] __kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320 kmalloc_noprof include/linux/slab.h:901 [inline] diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105 jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176 jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523 get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636 get_tree_bdev+0x37/0x50 fs/super.c:1659 jfs_get_tree+0x34/0x40 fs/jfs/super.c:635 vfs_get_tree+0xb1/0x5a0 fs/super.c:1814 do_new_mount+0x71f/0x15e0 fs/namespace.c:3560 path_mount+0x742/0x1f10 fs/namespace.c:3887 do_mount fs/namespace.c:3900 [inline] __do_sys_mount fs/namespace.c:4111 [inline] __se_sys_mount+0x71f/0x800 fs/namespace.c:4088 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4088 x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ===================================================== The reason is that imap is not properly initialized after memory allocation. It will cause the snprintf() function to write uninitialized data into linebuf within hex_dump_to_buffer(). Fix this by using kzalloc instead of kmalloc to clear its content at the beginning in diMount().", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37859", "url": "https://ubuntu.com/security/CVE-2025-37859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: page_pool: avoid infinite loop to schedule delayed worker We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1]. Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally. This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry(). [1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37862", "url": "https://ubuntu.com/security/CVE-2025-37862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: pidff: Fix null pointer dereference in pidff_find_fields This function triggered a null pointer dereference if used to search for a report that isn't implemented on the device. This happened both for optional and required reports alike. The same logic was applied to pidff_find_special_field and although pidff_init_fields should return an error earlier if one of the required reports is missing, future modifications could change this logic and resurface this possible null pointer dereference again. LKML bug report: https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37841", "url": "https://ubuntu.com/security/CVE-2025-37841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pm: cpupower: bench: Prevent NULL dereference on malloc failure If malloc returns NULL due to low memory, 'config' pointer can be NULL. Add a check to prevent NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-37748", "url": "https://ubuntu.com/security/CVE-2025-37748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group Currently, mtk_iommu calls during probe iommu_device_register before the hw_list from driver data is initialized. Since iommu probing issue fix, it leads to NULL pointer dereference in mtk_iommu_device_group when hw_list is accessed with list_first_entry (not null safe). So, change the call order to ensure iommu_device_register is called after the driver data are initialized.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37749", "url": "https://ubuntu.com/security/CVE-2025-37749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ppp: Add bound checking for skb data on ppp_sync_txmung Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets. When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef➤ p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { \ttype = 0x1, \tver = 0x1, \tcode = 0x0, \tsid = 0x2, length = 0x0, \ttag = 0xffff8880371cdb96 } from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 \"4\", data = 0xffff88803346f416 \":\\377\", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, it is not safe to access data[2]. [pabeni@redhat.com: fixed subj typo]", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37754", "url": "https://ubuntu.com/security/CVE-2025-37754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/huc: Fix fence not released on early probe errors HuC delayed loading fence, introduced with commit 27536e03271da (\"drm/i915/huc: track delayed HuC load with a fence\"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel: <4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] ... <4> [309.733806] ---[ end trace 0000000000000000 ]--- That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup step to driver release path. (cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37755", "url": "https://ubuntu.com/security/CVE-2025-37755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: handle page_pool_dev_alloc_pages error page_pool_dev_alloc_pages could return NULL. There was a WARN_ON(!page) but it would still proceed to use the NULL pointer and then crash. This is similar to commit 001ba0902046 (\"net: fec: handle page_pool_dev_alloc_pages error\"). This is found by our static analysis tool KNighter.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37757", "url": "https://ubuntu.com/security/CVE-2025-37757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix memory leak in tipc_link_xmit In case the backlog transmit queue for system-importance messages is overloaded, tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to memory leak and failure when a skb is allocated. This commit fixes this issue by purging the skb list before tipc_link_xmit() returns.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37758", "url": "https://ubuntu.com/security/CVE-2025-37758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe() devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does not check for this case, which can result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue.", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-37801", "url": "https://ubuntu.com/security/CVE-2025-37801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-imx: Add check for spi_imx_setupxfer() Add check for the return value of spi_imx_setupxfer(). spi_imx->rx and spi_imx->tx function pointer can be NULL when spi_imx_setupxfer() return error, and make NULL pointer dereference. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: 0x0 spi_imx_pio_transfer+0x50/0xd8 spi_imx_transfer_one+0x18c/0x858 spi_transfer_one_message+0x43c/0x790 __spi_pump_transfer_message+0x238/0x5d4 __spi_sync+0x2b0/0x454 spi_write_then_read+0x11c/0x200", "cve_priority": "medium", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2025-39946", "url": "https://ubuntu.com/security/CVE-2025-39946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: make sure to abort the stream if headers are bogus Normally we wait for the socket to buffer up the whole record before we service it. If the socket has a tiny buffer, however, we read out the data sooner, to prevent connection stalls. Make sure that we abort the connection when we find out late that the record is actually invalid. Retrying the parsing is fine in itself but since we copy some more data each time before we parse we can overflow the allocated skb space. Constructing a scenario in which we're under pressure without enough data in the socket to parse the length upfront is quite hard. syzbot figured out a way to do this by serving us the header in small OOB sends, and then filling in the recvbuf with a large normal send. Make sure that tls_rx_msg_size() aborts strp, if we reach an invalid record there's really no way to recover.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-38584", "url": "https://ubuntu.com/security/CVE-2025-38584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: Fix pd UAF once and for all There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-40019", "url": "https://ubuntu.com/security/CVE-2025-40019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: essiv - Check ssize for decryption and in-place encryption Move the ssize check to the start in essiv_aead_crypt so that it's also checked for decryption and in-place encryption.", "cve_priority": "medium", "cve_public_date": "2025-10-24 12:15:00 UTC" }, { "cve": "CVE-2025-38561", "url": "https://ubuntu.com/security/CVE-2025-38561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix Preauh_HashValue race condition If client send multiple session setup requests to ksmbd, Preauh_HashValue race condition could happen. There is no need to free sess->Preauh_HashValue at session setup phase. It can be freed together with session at connection termination phase.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-39698", "url": "https://ubuntu.com/security/CVE-2025-39698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/futex: ensure io_futex_wait() cleans up properly on failure The io_futex_data is allocated upfront and assigned to the io_kiocb async_data field, but the request isn't marked with REQ_F_ASYNC_DATA at that point. Those two should always go together, as the flag tells io_uring whether the field is valid or not. Additionally, on failure cleanup, the futex handler frees the data but does not clear ->async_data. Clear the data and the flag in the error path as well. Thanks to Trend Micro Zero Day Initiative and particularly ReDress for reporting this.", "cve_priority": "high", "cve_public_date": "2025-09-05 18:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-98.98 -proposed tracker (LP: #2137901)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.01.12)", "", " * ubuntu_kselftests:_net/net:gre_gso.sh failing (LP: #2136820)", " - SAUCE increase socat timeout in gre_gso.sh", "", " * TPM timeouts occur on some Infineon TPMs (LP: #2137528)", " - tpm: Make chip->{status,cancel,req_canceled} opt", " - tpm: Check for completion after timeout", "", " * power: intel_pstate: Fix unchecked MSR (LP: #2130244)", " - cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722)", " - selftests/futex: futex_waitv wouldblock test should fail", " - drm/i915/dg2: wait for HuC load completion before running selftests", " - drm/i915: Disable RPG during live selftest", " - objtool: Fix INSN_CONTEXT_SWITCH handling in validate_unret()", " - octeontx2-pf: qos: fix VF root node parent queue index", " - tc: Ensure we have enough buffer space when sending filter netlink", " notifications", " - net: ethtool: Don't call .cleanup_data when prepare_data fails", " - drm/tests: modeset: Fix drm_display_mode memory leak", " - drm/tests: helpers: Add atomic helpers", " - drm/tests: Add helper to create mock plane", " - drm/tests: Add helper to create mock crtc", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/tests: helpers: Fix compiler warning", " - drm/tests: helpers: Create kunit helper to destroy a drm_display_mode", " - drm/tests: cmdline: Fix drm_display_mode memory leak", " - drm/tests: modes: Fix drm_display_mode memory leak", " - drm/tests: probe-helper: Fix drm_display_mode memory leak", " - ata: sata_sx4: Add error handling in pdc20621_i2c_read()", " - nvmet-fcloop: swap list_add_tail arguments", " - net_sched: sch_sfq: use a temporary work area for validating", " configuration", " - Revert \"net_sched: sch_sfq: move the limit validation\"", " - net_sched: sch_sfq: move the limit validation", " - ipv6: Align behavior across nexthops during path selection", " - nft_set_pipapo: fix incorrect avx2 match of 5th field octet", " - fs: consistently deref the files table with rcu_dereference_raw()", " - umount: Allow superblock owners to force umount", " - x86/mm: Clear _PAGE_DIRTY for kernel mappings when we clear _PAGE_RW", " - x86/ia32: Leave NULL selector values 0~3 unchanged", " - x86/cpu: Don't clear X86_FEATURE_LAHF_LM flag in init_amd_k8() on AMD", " when running in a virtual machine", " - perf: arm_pmu: Don't disable counter in armpmu_add()", " - arm64: cputype: Add QCOM_CPU_PART_KRYO_3XX_GOLD", " - xen/mcelog: Add __nonstring annotations for unterminated strings", " - zstd: Increase DYNAMIC_BMI2 GCC version cutoff from 4.8 to 11.0 to work", " around compiler segfault", " - ASoC: SOF: topology: Use krealloc_array() to replace krealloc()", " - HID: pidff: Convert infinite length from Linux API to PID standard", " - HID: pidff: Do not send effect envelope if it's empty", " - HID: pidff: Add MISSING_DELAY quirk and its detection", " - HID: pidff: Add MISSING_PBO quirk and its detection", " - HID: pidff: Add PERMISSIVE_CONTROL quirk", " - HID: pidff: Add hid_pidff_init_with_quirks and export as GPL symbol", " - HID: pidff: Add FIX_WHEEL_DIRECTION quirk", " - HID: Add hid-universal-pidff driver and supported device ids", " - [Config] enable hid-universal-pidff driver", " - HID: pidff: Add PERIODIC_SINE_ONLY quirk", " - ALSA: hda: intel: Fix Optimus when GPU has no sound", " - ALSA: hda: intel: Add Lenovo IdeaPad Z570 to probe denylist", " - ASoC: fsl_audmix: register card device depends on 'dais' property", " - media: uvcvideo: Add quirk for Actions UVC05", " - mmc: dw_mmc: add a quirk for accessing 64-bit FIFOs in two halves", " - ALSA: usb-audio: Fix CME quirk for UF series keyboards", " - ASoC: amd: Add DMI quirk for ACP6X mic support", " - ASoC: amd: yc: update quirk data for new Lenovo model", " - f2fs: don't retry IO for corrupted data scenario", " - scsi: target: spc: Fix RSOC parameter data header size", " - net: usb: asix_devices: add FiberGecko DeviceID", " - fs/jfs: cast inactags to s64 to prevent potential overflow", " - ata: libata-eh: Do not use ATAPI DMA for a device limited to PIO mode", " - net: sfp: add quirk for 2.5G OEM BX SFP", " - ahci: add PCI ID for Marvell 88SE9215 SATA Controller", " - ext4: protect ext4_release_dquot against freezing", " - Revert \"f2fs: rebuild nat_bits during umount\"", " - cdc_ether|r8152: ThinkPad Hybrid USB-C/A Dock quirk", " - wifi: mt76: mt76x2u: add TP-Link TL-WDN6200 ID to device table", " - tracing: fix return value in __ftrace_event_enable_disable for", " TRACE_REG_UNREGISTER", " - Bluetooth: hci_uart: fix race during initialization", " - Bluetooth: qca: simplify WCN399x NVM loading", " - drm: allow encoder mode_set even when connectors change for crtc", " - drm/amd/display: Update Cursor request mode to the beginning prefetch", " always", " - drm/amd/display: add workaround flag to link to force FFE preset", " - drm: panel-orientation-quirks: Add support for AYANEO 2S", " - drm: panel-orientation-quirks: Add quirks for AYA NEO Flip DS and KB", " - drm: panel-orientation-quirks: Add quirk for AYA NEO Slide", " - drm: panel-orientation-quirks: Add new quirk for GPD Win 2", " - drm: panel-orientation-quirks: Add quirk for OneXPlayer Mini (Intel)", " - drm/bridge: panel: forbid initializing a panel with unknown connector", " type", " - drivers: base: devres: Allow to release group on device release", " - drm/amdkfd: clamp queue size to minimum", " - drm/amdkfd: Fix pqm_destroy_queue race with GPU reset", " - drm/mediatek: mtk_dpi: Move the input_2p_en bit to platform data", " - drm/mediatek: mtk_dpi: Explicitly manage TVD clock in power on/off", " - drm/amdgpu: grab an additional reference on the gang fence v2", " - tracing: probe-events: Add comments about entry data storing code", " - ktest: Fix Test Failures Due to Missing LOG_FILE Directories", " - tpm, tpm_tis: Workaround failed command reception on Infineon devices", " - pwm: rcar: Improve register calculation", " - pwm: fsl-ftm: Handle clk_get_rate() returning 0", " - bpf: support SKF_NET_OFF and SKF_LL_OFF on skb frags", " - ext4: don't treat fhandle lookup of ea_inode as FS corruption", " - dt-bindings: media: st,stmipid02: correct lane-polarities maxItems", " - media: mtk-vcodec: venc: avoid -Wenum-compare-conditional warning", " - media: i2c: adv748x: Fix test pattern selection mask", " - media: vim2m: print device name after registering device", " - media: siano: Fix error handling in smsdvb_module_init()", " - xenfs/xensyms: respect hypervisor's \"next\" indication", " - arm64: cputype: Add MIDR_CORTEX_A76AE", " - arm64: errata: Add QCOM_KRYO_4XX_GOLD to the spectre_bhb_k24_list", " - arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB", " - arm64: errata: Add KRYO 2XX/3XX/4XX silver cores to Spectre BHB safe", " list", " - spi: cadence-qspi: Fix probe on AM62A LP SK", " - tpm, tpm_tis: Fix timeout handling when waiting for TPM status", " - media: streamzap: prevent processing IR data on URB failure", " - media: visl: Fix ERANGE error when setting enum controls", " - media: platform: stm32: Add check for clk_enable()", " - media: v4l2-dv-timings: prevent possible overflow in v4l2_detect_gtf()", " - media: i2c: ccs: Set the device's runtime PM status correctly in remove", " - media: i2c: ccs: Set the device's runtime PM status correctly in probe", " - media: i2c: ov7251: Set enable GPIO low in probe", " - media: i2c: ov7251: Introduce 1 ms delay between regulators and en GPIO", " - media: i2c: imx219: Rectify runtime PM handling in probe and remove", " - mptcp: sockopt: fix getting IPV6_V6ONLY", " - mtd: Add check for devm_kcalloc()", " - net: dsa: mv88e6xxx: workaround RGMII transmit delay erratum for 6320", " family", " - mtd: Replace kcalloc() with devm_kcalloc()", " - clocksource/drivers/stm32-lptimer: Use wakeup capable instead of init", " wakeup", " - wifi: mt76: Add check for devm_kstrdup()", " - wifi: mac80211: fix integer overflow in hwmp_route_info_get()", " - io_uring/kbuf: reject zero sized provided buffers", " - ASoC: q6apm: add q6apm_get_hw_pointer helper", " - ASoC: qdsp6: q6apm-dai: set 10 ms period and buffer alignment.", " - ASoC: qdsp6: q6apm-dai: fix capture pipeline overruns.", " - ASoC: qdsp6: q6asm-dai: fix q6asm_dai_compr_set_params error path", " - f2fs: fix to avoid atomicity corruption of atomic file", " - vdpa/mlx5: Fix oversized null mkey longer than 32bit", " - udf: Fix inode_getblk() return value", " - smb311 client: fix missing tcon check when mounting with linux/posix", " extensions", " - i3c: master: svc: Use readsb helper for reading MDB", " - leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs", " - leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs", " - mailbox: tegra-hsp: Define dimensioning masks in SoC data", " - locking/lockdep: Decrease nr_unused_locks if lock unused in zap_class()", " - lib: scatterlist: fix sg_split_phys to preserve original scatterlist", " offsets", " - mptcp: only inc MPJoinAckHMacFailure for HMAC failures", " - mtd: rawnand: Add status chack in r852_ready()", " - arm64: mm: Correct the update of max_pfn", " - arm64: dts: mediatek: mt8173: Fix disp-pwm compatible string", " - btrfs: fix non-empty delayed iputs list on unmount due to compressed", " write workers", " - btrfs: zoned: fix zone activation with missing devices", " - btrfs: zoned: fix zone finishing with missing devices", " - iommufd: Fix uninitialized rc in iommufd_access_rw()", " - sparc/mm: disable preemption in lazy mmu mode", " - sparc/mm: avoid calling arch_enter/leave_lazy_mmu() in set_ptes", " - mm/rmap: reject hugetlb folios in folio_make_device_exclusive()", " - mm: make page_mapped_in_vma() hugetlb walk aware", " - mm: fix lazy mmu docs and usage", " - mm/mremap: correctly handle partial mremap() of VMA starting at 0", " - mm: add missing release barrier on PGDAT_RECLAIM_LOCKED unlock", " - mm/userfaultfd: fix release hang over concurrent GUP", " - mm/hwpoison: do not send SIGBUS to processes with recovered clean pages", " - mm/hugetlb: move hugetlb_sysctl_init() to the __init section", " - x86/xen: fix balloon target initialization for PVH dom0", " - tracing: Do not add length to print format in synthetic events", " - thermal/drivers/rockchip: Add missing rk3328 mapping entry", " - cifs: fix integer overflow in match_server()", " - clk: qcom: clk-branch: Fix invert halt status bit check for votable", " clocks", " - clk: qcom: gdsc: Release pm subdomains in reverse add order", " - clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code", " - clk: qcom: gdsc: Set retain_ff before moving to HW CTRL", " - crypto: ccp - Fix check for the primary ASP device", " - dm-ebs: fix prefetch-vs-suspend race", " - dm-integrity: set ti->error on memory allocation failure", " - dm-verity: fix prefetch-vs-suspend race", " - dt-bindings: coresight: qcom,coresight-tpda: Fix too many 'reg'", " - dt-bindings: coresight: qcom,coresight-tpdm: Fix too many 'reg'", " - gpio: tegra186: fix resource handling in ACPI probe path", " - gpio: zynq: Fix wakeup source leaks on device unbind", " - gve: handle overflow when reporting TX consumed descriptors", " - KVM: x86: Explicitly zero-initialize on-stack CPUID unions", " - ntb: use 64-bit arithmetic for the MSI doorbell mask", " - of/irq: Fix device node refcount leakage in API of_irq_parse_one()", " - of/irq: Fix device node refcount leakage in API of_irq_parse_raw()", " - of/irq: Fix device node refcount leakages in of_irq_count()", " - of/irq: Fix device node refcount leakage in API irq_of_parse_and_map()", " - of/irq: Fix device node refcount leakages in of_irq_init()", " - PCI: brcmstb: Fix missing of_node_put() in brcm_pcie_probe()", " - PCI: Fix reference leak in pci_alloc_child_bus()", " - phy: freescale: imx8m-pcie: assert phy reset and perst in power off", " - pinctrl: qcom: Clear latched interrupt status when changing IRQ type", " - selftests: mptcp: close fd_in before returning in main_loop", " - selftests: mptcp: fix incorrect fd checks in main_loop", " - arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected()", " lists", " - ACPI: platform-profile: Fix CFI violation when accessing sysfs files", " - iommufd: Fail replace if device has not been attached", " - x86/e820: Fix handling of subpage regions when calculating nosave ranges", " in e820__register_nosave_regions()", " - media: mediatek: vcodec: mark vdec_vp9_slice_map_counts_eob_coef", " noinline", " - Bluetooth: hci_uart: Fix another race during initialization", " - scsi: hisi_sas: Enable force phy when SATA disk directly connected", " - wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()", " - scsi: iscsi: Fix missing scsi_host_put() in error path", " - md/raid10: fix missing discard IO accounting", " - md/md-bitmap: fix stats collection for external bitmaps", " - ASoC: dwc: always enable/disable i2s irqs", " - ovl: remove unused forward declaration", " - RDMA/usnic: Fix passing zero to PTR_ERR in usnic_ib_pci_probe()", " - RDMA/hns: Fix wrong maximum DMA segment size", " - ASoC: cs42l43: Reset clamp override on jack removal", " - Bluetooth: hci_event: Fix sending MGMT_EV_DEVICE_FOUND for invalid", " address", " - Bluetooth: l2cap: Check encryption key size on incoming connection", " - Revert \"wifi: mac80211: Update skb's control block key in", " ieee80211_tx_dequeue()\"", " - igc: increase wait time before retrying PTM", " - igc: move ktime snapshot into PTM retry loop", " - igc: handle the IGC_PTP_ENABLED flag correctly", " - igc: cleanup PTP module if probe fails", " - igc: add lock preventing multiple simultaneous PTM transactions", " - test suite: use %zu to print size_t", " - pds_core: fix memory leak in pdsc_debugfs_add_qcq()", " - net: ethernet: ti: am65-cpsw-nuss: rename phy_node -> port_np", " - net: ethernet: ti: am65-cpsw: fix port_np reference counting", " - ata: libata-sata: Save all fields from sense data descriptor", " - netlink: specs: rt-link: add an attr layer around alt-ifname", " - netlink: specs: rt-link: adjust mctp attribute naming", " - net: b53: enable BPDU reception for management port", " - net: bridge: switchdev: do not notify new brentries as changed", " - net: dsa: avoid refcount warnings when ds->ops->tag_8021q_vlan_del()", " fails", " - ptp: ocp: fix start time alignment in ptp_ocp_signal_set", " - net: ti: icss-iep: Add pwidth configuration for perout signal", " - net: ti: icss-iep: Add phase offset configuration for perout signal", " - net: ethernet: mtk_eth_soc: correct the max weight of the queue limit", " for 100Mbps", " - net: ethernet: mtk_eth_soc: revise QDMA packet scheduler settings", " - riscv: Properly export reserved regions in /proc/iomem", " - kunit: qemu_configs: SH: Respect kunit cmdline", " - riscv: KGDB: Do not inline arch_kgdb_breakpoint()", " - riscv: KGDB: Remove \".option norvc/.option rvc\" for kgdb_compiled_break", " - cpufreq/sched: Fix the usage of CPUFREQ_NEED_UPDATE_LIMITS", " - writeback: fix false warning in inode_to_wb()", " - ASoC: codecs:lpass-wsa-macro: Fix vi feedback rate", " - ASoC: codecs:lpass-wsa-macro: Fix logic of enabling vi channels", " - asus-laptop: Fix an uninitialized variable", " - nfs: add missing selections of CONFIG_CRC32", " - nfsd: decrease sc_count directly if fail to queue dl_recall", " - i2c: atr: Fix wrong include", " - ftrace: fix incorrect hash size in register_ftrace_direct()", " - Bluetooth: l2cap: Process valid commands in too long frame", " - Bluetooth: vhci: Avoid needless snprintf() calls", " - btrfs: correctly escape subvol in btrfs_show_options()", " - crypto: caam/qi - Fix drv_ctx refcount bug", " - Revert \"UBUNTU: SAUCE: fs: hfs/hfsplus: add key_len boundary check to", " hfs_bnode_read_key\"", " - hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key", " - loop: properly send KOBJ_CHANGED uevent for disk device", " - loop: LOOP_SET_FD: send uevents for partitions", " - mm/gup: fix wrongly calculated returned value in", " fault_in_safe_writeable()", " - mm: fix filemap_get_folios_contig returning batches of identical folios", " - mm: fix apply_to_existing_page_range()", " - ksmbd: Prevent integer overflow in calculation of deadtime", " - Revert \"smb: client: fix TCP timers deadlock after rmmod\"", " - riscv: Avoid fortify warning in syscall_get_arguments()", " - selftests/mm: generate a temporary mountpoint for cgroup filesystem", " - smb3 client: fix open hardlink on deferred close file error", " - string: Add load_unaligned_zeropad() code path to sized_strscpy()", " - tracing: Fix filter string testing", " - x86/microcode/AMD: Extend the SHA check to Zen5, block loading of any", " unreleased standalone Zen5 microcode patches", " - x86/cpu/amd: Fix workaround for erratum 1054", " - x86/boot/sev: Avoid shared GHCB page for early memory acceptance", " - scsi: megaraid_sas: Block zero-length ATA VPD inquiry", " - scsi: ufs: exynos: Ensure consistent phy reference counts", " - perf/x86/intel: Allow to update user space GPRs from PEBS records", " - perf/x86/intel/uncore: Fix the scale of IIO free running counters on SNR", " - perf/x86/intel/uncore: Fix the scale of IIO free running counters on ICX", " - perf/x86/intel/uncore: Fix the scale of IIO free running counters on SPR", " - drm/repaper: fix integer overflows in repeat functions", " - drm/msm/a6xx: Fix stale rpmh votes from GPU", " - drm/amd: Handle being compiled without SI or CIK support better", " - drm/amdgpu/dma_buf: fix page_link check", " - drm/sti: remove duplicate object names", " - drm/i915/gvt: fix unterminated-string-initialization warning", " - io_uring/net: fix accept multishot handling", " - cpufreq: Reference count policy in cpufreq_update_limits()", " - kbuild: Add '-fno-builtin-wcslen'", " - mptcp: sockopt: fix getting freebind & transparent", " - misc: pci_endpoint_test: Fix 'irq_type' to convey the correct type", " - efi/libstub: Bump up EFI_MMAP_NR_SLACK_SLOTS to 32", " - x86/xen: move xen_reserve_extra_memory()", " - x86/xen: fix memblock_reserve() usage on PVH", " - x86/split_lock: Fix the delayed detection logic", " - LoongArch: Eliminate superfluous get_numa_distances_cnt()", " - Revert \"usb: typec: fix potential array underflow in", " ucsi_ccg_sync_control()\"", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - usb: typec: fix pm usage counter imbalance in ucsi_ccg_sync_control()", " - landlock: Add the errata interface", " - nvmet-fc: Remove unused functions", " - xdp: Reset bpf_redirect_info before running a xdp's BPF prog.", " - sign-file,extract-cert: move common SSL helper functions to a header", " - sign-file,extract-cert: avoid using deprecated ERR_get_error_line()", " - sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3", " - MIPS: dec: Declare which_prom() as static", " - MIPS: cevt-ds1287: Add missing ds1287.h include", " - MIPS: ds1287: Match ds1287_set_base_clock() function types", " - drm/tests: Build KMS helpers when DRM_KUNIT_TEST_HELPERS is enabled", " - ASoC: Intel: adl: add 2xrt1316 audio configuration", " - cgroup/cpuset: Fix incorrect isolated_cpus update in", " update_parent_effective_cpumask()", " - cgroup/cpuset: Correct invalid remote parition prs", " - cgroup/cpuset: Fix error handling in remote_partition_disable()", " - cgroup/cpuset: Revert \"Allow suppression of sched domain rebuild in", " update_cpumasks_hier()\"", " - cgroup/cpuset: Enforce at most one rebuild_sched_domains_locked() call", " per operation", " - cgroup/cpuset: Further optimize code if CONFIG_CPUSETS_V1 not set", " - cgroup/cpuset: Fix race between newly created partition and dying one", " - gpiolib: of: Fix the choice for Ingenic NAND quirk", " - ublk: refactor recovery configuration flag helpers", " - net: phy: move phy_link_change() prior to mdio_bus_phy_may_suspend()", " - iommu/exynos: Fix suspend/resume with IDENTITY domain", " - perf/dwc_pcie: fix some unreleased resources", " - Flush console log from kernel_power_off()", " - ASoC: amd: ps: use macro for ACP6.3 pci revision id", " - media: s5p-mfc: Corrected NV12M/NV21M plane-sizes", " - wifi: ath11k: Fix DMA buffer allocation to resolve SWIOTLB issues", " - wifi: ath11k: fix memory leak in ath11k_xxx_remove()", " - wifi: mac80211: ensure sdata->work is canceled before initialized.", " - can: flexcan: Add quirk to handle separate interrupt lines for mailboxes", " - can: flexcan: add NXP S32G2/S32G3 SoC support", " - Bluetooth: btusb: Add 2 HWIDs for MT7922", " - Bluetooth: Add quirk for broken READ_VOICE_SETTING", " - Bluetooth: Add quirk for broken READ_PAGE_SCAN_TYPE", " - drm/debugfs: fix printk format for bridge index", " - drm/amd/display: stop DML2 from removing pipes based on planes", " - drm/xe/xelp: Move Wa_16011163337 from tunings to workarounds", " - PCI: Add Rockchip Vendor ID", " - HID: pidff: Clamp PERIODIC effect period to device's logical range", " - HID: pidff: Stop all effects before enabling actuators", " - HID: pidff: Completely rework and fix pidff_reset function", " - HID: pidff: Simplify pidff_upload_effect function", " - HID: pidff: Define values used in pidff_find_special_fields", " - HID: pidff: Rescale time values to match field units", " - HID: pidff: Factor out code for setting gain", " - HID: pidff: Move all hid-pidff definitions to a dedicated header", " - HID: pidff: Simplify pidff_rescale_signed", " - HID: pidff: Use macros instead of hardcoded min/max values for shorts", " - HID: pidff: Factor out pool report fetch and remove excess declaration", " - HID: hid-universal-pidff: Add Asetek wheelbases support", " - HID: pidff: Comment and code style update", " - HID: pidff: Support device error response from PID_BLOCK_LOAD", " - HID: pidff: Remove redundant call to pidff_find_special_keys", " - HID: pidff: Rename two functions to align them with naming convention", " - HID: pidff: Clamp effect playback LOOP_COUNT value", " - HID: pidff: Compute INFINITE value instead of using hardcoded 0xffff", " - HID: pidff: Fix 90 degrees direction name North -> East", " - HID: pidff: Fix set_device_control()", " - media: mgb4: Fix CMT registers update logic", " - media: mgb4: Fix switched CMT frequency range \"magic values\" sets", " - media: rockchip: rga: fix rga offset lookup", " - media: v4l: Add a helper for setting up link-frequencies control", " - media: v4l2-common.h: kerneldoc: correctly format return values", " - media: imx219: Adjust PLL settings based on the number of MIPI lanes", " - media: nuvoton: Fix reference handling of ece_node", " - media: nuvoton: Fix reference handling of ece_pdev", " - media: i2c: imx319: Rectify runtime PM handling probe and remove", " - media: i2c: imx214: Rectify probe error handling related to runtime PM", " - media: chips-media: wave5: Fix gray color on screen", " - media: chips-media: wave5: Fix a hang after seeking", " - wifi: mt76: mt7925: ensure wow pattern command align fw format", " - wifi: mt76: mt7925: fix country count limitation for CLC", " - ALSA: hda/realtek: Enable Mute LED on HP OMEN 16 Laptop xd000xx", " - accel/ivpu: Fix warning in ivpu_ipc_send_receive_internal()", " - ima: limit the number of open-writers integrity violations", " - arm64: dts: exynos: gs101: disable pinctrl_gsacore node", " - btrfs: tests: fix chunk map leak after failure to add it to the tree", " - mm/damon/ops: have damon_get_folio return folio even for tail pages", " - CIFS: Propagate min offload along with other parameters from primary to", " secondary channels.", " - dm-integrity: fix non-constant-time tag verification", " - landlock: Move code to ease future backports", " - landlock: Add erratum for TCP fix", " - misc: pci_endpoint_test: Fix displaying 'irq_type' after 'request_irq'", " error", " - net: mana: Switch to page pool for jumbo frames", " - PCI: j721e: Fix the value of .linkdown_irq_regfield for J784S4", " - pinctrl: samsung: add support for eint_fltcon_offset", " - s390/virtio_ccw: Don't allocate/assign airqs for non-existing queues", " - thermal/drivers/mediatek/lvts_thermal: Allow early empty sensor slots", " - thermal/drivers/mediatek/lvts_thermal: Fix wrong lvts_ctrl index", " - thermal/drivers/mediatek/lvts: Disable monitor mode during suspend", " - thermal/drivers/mediatek/lvts: Disable Stage 3 thermal threshold", " - NFSD: fix decoding in nfs4_xdr_dec_cb_getattr", " - libbpf: Prevent compiler warnings/errors", " - Upstream stable to v6.6.88, v6.12.24", " - SAUCE: Enable upstream config option \"CONFIG_CPUSETS_V1\"", "", " * [SRU] ixgbe: Add support for E610 in Noble (LP: #2131265)", " - ixgbe: Add support for E610 FW Admin Command Interface", " - ixgbe: Add support for E610 device capabilities detection", " - ixgbe: Add link management support for E610 device", " - ixgbe: Add support for NVM handling in E610 device", " - ixgbe: Add support for EEPROM dump in E610 device", " - ixgbe: Add ixgbe_x540 multiple header inclusion protection", " - ixgbe: Clean up the E610 link management related code", " - ixgbe: Enable link management in E610 device", " - ixgbe: fix media type detection for E610 device", " - ixgbe: fix media cage present detection for E610 device", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586)", " - io_uring: don't use int for ABI", " - ALSA: hda/realtek: Fix headset mic on HONOR BRB-X", " - ALSA: hda/realtek: Add Framework Laptop 13 (AMD Ryzen AI 300) to quirks", " - smb: client: remove redundant lstrp update in negotiate protocol", " - gpio: virtio: Fix config space reading.", " - gpio: mlxbf2: use platform_get_irq_optional()", " - gpio: mlxbf3: use platform_get_irq_optional()", " - netlink: avoid infinite retry looping in netlink_unicast()", " - net: phy: micrel: fix KSZ8081/KSZ8091 cable test", " - net: gianfar: fix device leak when querying time stamp info", " - net: enetc: fix device and OF node leak at probe", " - net: mtk_eth_soc: fix device leak at probe", " - net: ti: icss-iep: fix device and OF node leaks at probe", " - net: dpaa: fix device leak when querying time stamp info", " - NFSD: detect mismatch of file handle and delegation stateid in OPEN op", " - PCI: Extend isolated function probing to LoongArch", " - LoongArch: BPF: Fix jump offset calculation in tailcall", " - sunvdc: Balance device refcount in vdc_port_mpgroup_check", " - Documentation: ACPI: Fix parent device references", " - ACPI: processor: perflib: Fix initial _PPC limit application", " - ACPI: processor: perflib: Move problematic pr->performance check", " - smb: client: let send_done() cleanup before calling", " smbd_disconnect_rdma_connection()", " - smb: client: don't wait for info->send_pending == 0 on error", " - KVM: x86: Plumb \"force_immediate_exit\" into kvm_entry() tracepoint", " - KVM: VMX: Re-enter guest in fastpath for \"spurious\" preemption timer", " exits", " - KVM: VMX: Handle forced exit due to preemption timer in fastpath", " - KVM: x86: Move handling of is_guest_mode() into fastpath exit handlers", " - KVM: VMX: Handle KVM-induced preemption timer exits in fastpath for L2", " - KVM: x86: Fully defer to vendor code to decide how to force immediate", " exit", " - KVM: x86: Convert vcpu_run()'s immediate exit param into a generic", " bitmap", " - KVM: x86: Drop kvm_x86_ops.set_dr6() in favor of a new KVM_RUN flag", " - KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is supported", " - KVM: VMX: Extract checking of guest's DEBUGCTL into helper", " - KVM: nVMX: Check vmcs12->guest_ia32_debugctl on nested VM-Enter", " - KVM: VMX: Wrap all accesses to IA32_DEBUGCTL with getter/setter APIs", " - KVM: VMX: Preserve host's DEBUGCTLMSR_FREEZE_IN_SMM while running the", " guest", " - udp: also consider secpath when evaluating ipsec use for checksumming", " - net: ti: icss-iep: Fix incorrect type for return value in extts_enable()", " - intel_idle: Allow loading ACPI tables for any family", " - ptp: prevent possible ABBA deadlock in ptp_clock_freerun()", " - arm64: Handle KCOV __init vs inline mismatches", " - nvme-pci: try function level reset on init failure", " - udf: Verify partition map count", " - hfs: fix not erasing deleted b-tree node issue", " - better lockdep annotations for simple_recursive_removal()", " - ata: libata-sata: Disallow changing LPM state if not supported", " - fs/ntfs3: correctly create symlink for relative path", " - ext2: Handle fiemap on empty files to prevent EINVAL", " - fix locking in efi_secret_unlink()", " - securityfs: don't pin dentries twice, once is enough...", " - tracefs: Add d_delete to remove negative dentries", " - usb: xhci: print xhci->xhc_state when queue_command failed", " - platform/x86/amd: pmc: Add Lenovo Yoga 6 13ALC6 to pmc quirk list", " - cpufreq: CPPC: Mark driver with NEED_UPDATE_LIMITS flag", " - selftests/futex: Define SYS_futex on 32-bit architectures with 64-bit", " time_t", " - usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default", " - usb: xhci: Avoid showing warnings for dying controller", " - usb: xhci: Set avg_trb_len = 8 for EP0 during Address Device Command", " - usb: xhci: Avoid showing errors during surprise removal", " - soc: qcom: rpmh-rsc: Add RSC version 4 support", " - remoteproc: imx_rproc: skip clock enable when M-core is managed by the", " SCU", " - gpio: wcd934x: check the return value of regmap_update_bits()", " - cpufreq: Exit governor when failed to start old governor", " - PM / devfreq: governor: Replace sscanf() with kstrtoul() in", " set_freq_store()", " - EDAC/synopsys: Clear the ECC counters on init", " - ASoC: soc-dapm: set bias_level if snd_soc_dapm_set_bias_level() was", " successed", " - thermal/drivers/qcom-spmi-temp-alarm: Enable stage 2 shutdown when", " required", " - tools/nolibc: define time_t in terms of __kernel_old_time_t", " - iio: adc: ad_sigma_delta: don't overallocate scan buffer", " - gpio: tps65912: check the return value of regmap_update_bits()", " - tools/build: Fix s390(x) cross-compilation with clang", " - selftests: tracing: Use mutex_unlock for testing glob filter", " - ACPI: PRM: Reduce unnecessary printing to avoid user confusion", " - firmware: tegra: Fix IVC dependency problems", " - PM: runtime: Clear power.needs_force_resume in pm_runtime_reinit()", " - thermal: sysfs: Return ENODATA instead of EAGAIN for reads", " - PM: sleep: console: Fix the black screen issue", " - ACPI: processor: fix acpi_object initialization", " - mmc: sdhci-msm: Ensure SD card power isn't ON when card removed", " - ACPI: APEI: GHES: add TAINT_MACHINE_CHECK on GHES panic path", " - pps: clients: gpio: fix interrupt handling order in remove path", " - reset: brcmstb: Enable reset drivers for ARCH_BCM2835", " - char: misc: Fix improper and inaccurate error code returned by", " misc_init()", " - mei: bus: Check for still connected devices in mei_cl_bus_dev_release()", " - mmc: rtsx_usb_sdmmc: Fix error-path in sd_set_power_mode()", " - ALSA: hda: Handle the jack polling always via a work", " - ALSA: hda: Disable jack polling at shutdown", " - x86/bugs: Avoid warning when overriding return thunk", " - ASoC: hdac_hdmi: Rate limit logging on connection and disconnection", " - ALSA: intel8x0: Fix incorrect codec index usage in mixer for ICH4", " - usb: typec: intel_pmc_mux: Defer probe if SCU IPC isn't present", " - usb: core: usb_submit_urb: downgrade type check", " - pm: cpupower: Fix the snapshot-order of tsc,mperf, clock in mperf_stop()", " - imx8m-blk-ctrl: set ISI panic write hurry level", " - soc: qcom: mdt_loader: Actually use the e_phoff", " - platform/x86: thinkpad_acpi: Handle KCOV __init vs inline mismatches", " - platform/chrome: cros_ec_typec: Defer probe on missing EC parent", " - ALSA: hda/ca0132: Fix buffer overflow in add_tuning_control", " - ALSA: pcm: Rewrite recalculate_boundary() to avoid costly loop", " - ALSA: usb-audio: Avoid precedence issues in mixer_quirks macros", " - iio: adc: ad7768-1: Ensure SYNC_IN pulse minimum timing requirement", " - ASoC: codecs: rt5640: Retry DEVICE_ID verification", " - ASoC: qcom: use drvdata instead of component to keep id", " - powerpc/thp: tracing: Hide hugepage events under CONFIG_PPC_BOOK3S_64", " - Bluetooth: hci_sock: Reset cookie to zero in hci_sock_free_cookie()", " - xen/netfront: Fix TX response spurious interrupts", " - net: usb: cdc-ncm: check for filtering capability", " - ktest.pl: Prevent recursion of default variable options", " - wifi: cfg80211: reject HTC bit for management frames", " - s390/time: Use monotonic clock in get_cycles()", " - be2net: Use correct byte order and format string for TCP seq and ack_seq", " - wifi: rtw89: Lower the timeout in rtw89_fw_read_c2h_reg() for USB", " - et131x: Add missing check after DMA map", " - net: ag71xx: Add missing check after DMA map", " - net/mlx5e: Properly access RCU protected qdisc_sleeping variable", " - arm64: Mark kernel as tainted on SAE and SError panic", " - net: mctp: Prevent duplicate binds", " - wifi: cfg80211: Fix interface type validation", " - net: ipv4: fix incorrect MTU in broadcast routes", " - net: thunderx: Fix format-truncation warning in bgx_acpi_match_id()", " - net: phy: micrel: Add ksz9131_resume()", " - perf/cxlpmu: Remove unintended newline from IRQ name format string", " - wifi: iwlwifi: mvm: set gtk id also in older FWs", " - um: Re-evaluate thread flags repeatedly", " - wifi: iwlwifi: mvm: fix scan request validation", " - s390/stp: Remove udelay from stp_sync_clock()", " - sched/fair: Bump sd->max_newidle_lb_cost when newidle balance fails", " - wifi: mac80211: don't complete management TX on SAE commit", " - (powerpc/512) Fix possible `dma_unmap_single()` on uninitialized pointer", " - ipv6: mcast: Check inet6_dev->dead under idev->mc_lock in", " __ipv6_dev_mc_inc().", " - wifi: mac80211: fix rx link assignment for non-MLO stations", " - drm/msm: use trylock for debugfs", " - wifi: rtw89: Fix rtw89_mac_power_switch() for USB", " - wifi: rtw89: Disable deep power saving for USB/SDIO", " - wifi: mt76: mt7915: mcu: re-init MCU before loading FW patch", " - kselftest/arm64: Specify SVE data when testing VL set in sve-ptrace", " - net: thunderbolt: Enable end-to-end flow control also in transmit", " - net: thunderbolt: Fix the parameter passing of", " tb_xdomain_enable_paths()/tb_xdomain_disable_paths()", " - net: atlantic: add set_power to fw_ops for atl2 to fix wol", " - net: fec: allow disable coalescing", " - drm/amd/display: Separate set_gsl from set_gsl_source_select", " - wifi: ath12k: Add memset and update default rate value in wmi tx", " completion", " - wifi: iwlwifi: dvm: fix potential overflow in rs_fill_link_cmd()", " - wifi: iwlwifi: fw: Fix possible memory leak in iwl_fw_dbg_collect", " - drm/amd/display: Fix 'failed to blank crtc!'", " - wifi: mac80211: update radar_required in channel context after channel", " switch", " - wifi: rtlwifi: fix possible skb memory leak in", " `_rtl_pci_rx_interrupt()`.", " - wifi: ath12k: Enable REO queue lookup table feature on QCN9274 hw2.0", " - powerpc: floppy: Add missing checks after DMA map", " - netmem: fix skb_frag_address_safe with unreadable skbs", " - wifi: iwlegacy: Check rate_idx range after addition", " - neighbour: add support for NUD_PERMANENT proxy entries", " - dpaa_eth: don't use fixed_phy_change_carrier", " - drm/amd: Allow printing VanGogh OD SCLK levels without setting dpm to", " manual", " - net: vlan: Make is_vlan_dev() a stub when VLAN is not configured", " - net: vlan: Replace BUG() with WARN_ON_ONCE() in vlan_dev_* stubs", " - gve: Return error for unknown admin queue command", " - net: dsa: b53: fix b53_imp_vlan_setup for BCM5325", " - net: dsa: b53: prevent GMII_PORT_OVERRIDE_CTRL access on BCM5325", " - net: dsa: b53: prevent DIS_LEARNING access on BCM5325", " - net: dsa: b53: prevent SWITCH_CTRL access on BCM5325", " - bpftool: Fix JSON writer resource leak in version command", " - ptp: Use ratelimite for freerun error message", " - wifi: rtlwifi: fix possible skb memory leak in", " _rtl_pci_init_one_rxdesc()", " - ionic: clean dbpage in de-init", " - net: ncsi: Fix buffer overflow in fetching version id", " - drm: renesas: rz-du: mipi_dsi: Add min check for VCLK range", " - drm/ttm: Should to return the evict error", " - uapi: in6: restore visibility of most IPv6 socket options", " - bpf: Make reg_not_null() true for CONST_PTR_TO_MAP", " - selftests/bpf: Fix a user_ringbuf failure with arm64 64KB page size", " - drm/amd/display: Avoid trying AUX transactions on disconnected ports", " - drm/ttm: Respect the shrinker core free target", " - net: dsa: b53: fix IP_MULTICAST_CTRL on BCM5325", " - vsock/virtio: Resize receive buffers so that each SKB fits in a 4K page", " - vhost: fail early when __vhost_add_used() fails", " - drm/amd/display: Only finalize atomic_obj if it was initialized", " - drm/amd/display: Avoid configuring PSR granularity if PSR-SU not", " supported", " - watchdog: sbsa: Adjust keepalive timeout to avoid MediaTek WS0 race", " condition", " - cifs: Fix calling CIFSFindFirst() for root path without msearch", " - crypto: hisilicon/hpre - fix dma unmap sequence", " - clk: tegra: periph: Fix error handling and resolve unsigned compare", " warning", " - mfd: axp20x: Set explicit ID for AXP313 regulator", " - phy: rockchip-pcie: Properly disable TEST_WRITE strobe signal", " - fs/orangefs: use snprintf() instead of sprintf()", " - watchdog: dw_wdt: Fix default timeout", " - hwmon: (emc2305) Set initial PWM minimum value during probe based on", " thermal state", " - clk: qcom: ipq5018: keep XO clock always on", " - MIPS: vpe-mt: add missing prototypes for vpe_{alloc,start,stop,free}", " - watchdog: iTCO_wdt: Report error if timeout configuration fails", " - crypto: jitter - fix intermediary handling", " - MIPS: lantiq: falcon: sysctrl: fix request memory check logic", " - media: v4l2-common: Reduce warnings about missing V4L2_CID_LINK_FREQ", " control", " - leds: leds-lp50xx: Handle reg to get correct multi_index", " - dmaengine: stm32-dma: configure next sg only if there are more than 2", " sgs", " - RDMA/core: reduce stack using in nldev_stat_get_doit()", " - power: supply: qcom_battmgr: Add lithium-polymer entry", " - scsi: mpt3sas: Correctly handle ATA device errors", " - scsi: mpi3mr: Correctly handle ATA device errors", " - pinctrl: stm32: Manage irq affinity settings", " - media: tc358743: Check I2C succeeded during probe", " - media: tc358743: Return an appropriate colorspace from tc358743_set_fmt", " - media: tc358743: Increase FIFO trigger level to 374", " - media: usb: hdpvr: disable zero-length read messages", " - media: uvcvideo: Fix bandwidth issue for Alcor camera", " - crypto: octeontx2 - add timeout for load_fvc completion poll", " - soundwire: amd: serialize amd manager resume sequence during pm_prepare", " - soundwire: Move handle_nested_irq outside of sdw_dev_lock", " - md: dm-zoned-target: Initialize return variable r to avoid uninitialized", " use", " - module: Prevent silent truncation of module name in delete_module(2)", " - i3c: add missing include to internal header", " - rtc: ds1307: handle oscillator stop flag (OSF) for ds1341", " - i3c: don't fail if GETHDRCAP is unsupported", " - i3c: master: Initialize ret in i3c_i2c_notifier_call()", " - dm-mpath: don't print the \"loaded\" message if registering fails", " - dm-table: fix checking for rq stackable devices", " - apparmor: use the condition in AA_BUG_FMT even with debug disabled", " - i2c: Force DLL0945 touchpad i2c freq to 100khz", " - f2fs: check the generic conditions first", " - kconfig: lxdialog: replace strcpy() with strncpy() in inputbox.c", " - vfio/type1: conditional rescheduling while pinning", " - kconfig: nconf: Ensure null termination where strncpy is used", " - scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans", " - scsi: target: core: Generate correct identifiers for PR OUT transport", " IDs", " - scsi: aacraid: Stop using PCI_IRQ_AFFINITY", " - vfio/mlx5: fix possible overflow in tracking max message size", " - ipmi: Use dev_warn_ratelimited() for incorrect message warnings", " - kconfig: gconf: avoid hardcoding model2 in on_treeview2_cursor_changed()", " - kconfig: gconf: fix potential memory leak in renderer_edited()", " - kconfig: lxdialog: fix 'space' to (de)select options", " - ipmi: Fix strcpy source and destination the same", " - net: phy: smsc: add proper reset flags for LAN8710A", " - ASoC: Intel: avs: Fix uninitialized pointer error in probe()", " - pNFS: Fix stripe mapping in block/scsi layout", " - pNFS: Fix disk addr range check in block/scsi layout", " - pNFS: Handle RPC size limit for layoutcommits", " - rtc: ds1307: remove clear of oscillator stop flag (OSF) in probe", " - scsi: lpfc: Remove redundant assignment to avoid memory leak", " - ASoC: fsl_sai: replace regmap_write with regmap_update_bits", " - cifs: reset iface weights when we cannot find a candidate", " - iommufd: Report unmapped bytes in the error path of", " iopt_unmap_iova_range", " - ext4: fix zombie groups in average fragment size lists", " - ext4: fix largest free orders lists corruption on mb_optimize_scan", " switch", " - misc: rtsx: usb: Ensure mmc child device is active when card is present", " - usb: typec: ucsi: Update power_supply on power role change", " - thunderbolt: Fix copy+paste error in match_service_id()", " - cdc-acm: fix race between initial clearing halt and open", " - btrfs: zoned: use filesystem size not disk size for reclaim decision", " - btrfs: abort transaction during log replay if walk_log_tree() failed", " - btrfs: zoned: do not remove unwritten non-data block group", " - btrfs: clear dirty status from extent buffer on error at", " insert_new_root()", " - btrfs: fix log tree replay failure due to file with 0 links and extents", " - btrfs: zoned: do not select metadata BG as finish target", " - parisc: Makefile: fix a typo in palo.conf", " - media: uvcvideo: Do not mark valid metadata as invalid", " - tools/nolibc: fix spelling of FD_SETBITMASK in FD_* macros", " - HID: magicmouse: avoid setting up battery timer when not needed", " - HID: apple: avoid setting up battery timer for devices without battery", " - rcu: Fix racy re-initialization of irq_work causing hangs", " - cpufreq: armada-8k: Fix off by one in armada_8k_cpufreq_free_table()", " - platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister()", " - m68k: Fix lost column on framebuffer debug console", " - usb: atm: cxacru: Merge cxacru_upload_firmware() into", " cxacru_heavy_init()", " - usb: gadget: udc: renesas_usb3: fix device leak at unbind", " - usb: musb: omap2430: fix device leak at unbind", " - usb: dwc3: meson-g12a: fix device leaks at unbind", " - bus: mhi: host: Fix endianness of BHI vector table", " - vt: keyboard: Don't process Unicode characters in K_OFF mode", " - vt: defkeymap: Map keycodes above 127 to K_HOLE", " - lib/crypto: mips/chacha: Fix clang build and remove unneeded byteswap", " - crypto: qat - lower priority for skcipher and aead algorithms", " - ksmbd: extend the connection limiting mechanism to support IPv6", " - tracing: fprobe-event: Sanitize wildcard for fprobe event name", " - ext4: check fast symlink for ea_inode correctly", " - ext4: fix fsmap end of range reporting with bigalloc", " - ext4: fix reserved gdt blocks handling in fsmap", " - ext4: don't try to clear the orphan_present feature block device is r/o", " - ext4: use kmalloc_array() for array space allocation", " - ext4: fix hole length calculation overflow in non-extent inodes", " - btrfs: zoned: fix write time activation failure for metadata block group", " - arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by default", " - arm64: dts: ti: k3-am62a7-sk: fix pinmux for main_uart1", " - arm64: dts: ti: k3-am62-verdin: Enable pull-ups on I2C buses", " - dt-bindings: display: sprd,sharkl3-dpu: Fix missing clocks constraints", " - dt-bindings: display: sprd,sharkl3-dsi-host: Fix missing clocks", " constraints", " - scsi: mpi3mr: Fix race between config read submit and interrupt", " completion", " - ata: libata-scsi: Fix ata_to_sense_error() status handling", " - scsi: ufs: ufs-pci: Fix hibernate state transition for Intel MTL-like", " host controllers", " - scsi: ufs: ufs-pci: Fix default runtime and system PM levels", " - ata: libata-scsi: Fix CDL control", " - zynq_fpga: use sgtable-based scatterlist wrappers", " - iio: adc: ad_sigma_delta: change to buffer predisable", " - wifi: brcmsmac: Remove const from tbl_ptr parameter in", " wlc_lcnphy_common_read_table()", " - wifi: ath12k: fix dest ring-buffer corruption", " - wifi: ath12k: fix source ring-buffer corruption", " - wifi: ath12k: fix dest ring-buffer corruption when ring is full", " - wifi: ath11k: fix dest ring-buffer corruption", " - wifi: ath11k: fix source ring-buffer corruption", " - wifi: ath11k: fix dest ring-buffer corruption when ring is full", " - pwm: imx-tpm: Reset counter if CMOD is 0", " - pwm: mediatek: Handle hardware enable and clock enable separately", " - pwm: mediatek: Fix duty and period setting", " - hwmon: (gsc-hwmon) fix fan pwm setpoint show functions", " - mtd: spi-nor: Fix spi_nor_try_unlock_all()", " - mtd: spinand: propagate spinand_wait() errors from spinand_write_page()", " - mtd: rawnand: fsmc: Add missing check after DMA map", " - mtd: rawnand: renesas: Add missing check after DMA map", " - PCI: endpoint: Fix configfs group removal on driver teardown", " - vhost/vsock: Avoid allocating arbitrarily-sized SKBs", " - phy: qcom: phy-qcom-m31: Update IPQ5332 M31 USB phy initialization", " sequence", " - soc/tegra: pmc: Ensure power-domains are in a known state", " - parisc: Check region is readable by user in raw_copy_from_user()", " - parisc: Define and use set_pte_at()", " - parisc: Makefile: explain that 64BIT requires both 32-bit and 64-bit", " compilers", " - parisc: Rename pte_needs_flush() to pte_needs_cache_flush() in cache.c", " - parisc: Try to fixup kernel exception in bad_area_nosemaphore path of", " do_page_fault()", " - parisc: Update comments in make_insert_tlb", " - media: gspca: Add bounds checking to firmware parser", " - media: hi556: correct the test pattern configuration", " - media: imx: fix a potential memory leak in", " imx_media_csc_scaler_device_init()", " - media: vivid: fix wrong pixel_array control size", " - media: verisilicon: Fix AV1 decoder clock frequency", " - media: v4l2-ctrls: Don't reset handler's error in", " v4l2_ctrl_handler_free()", " - media: ov2659: Fix memory leaks in ov2659_probe()", " - media: qcom: camss: cleanup media device allocated resource on error", " path", " - media: venus: hfi: explicitly release IRQ during teardown", " - media: venus: vdec: Clamp param smaller than 1fps and bigger than 240.", " - media: venus: venc: Clamp param smaller than 1fps and bigger than 240", " - drm/amd: Restore cached power limit during resume", " - drm/amdgpu: update mmhub 3.0.1 client id mappings", " - drm/amd/display: Add primary plane to commits for correct VRR handling", " - drm/amd/display: Don't overwrite dce60_clk_mgr", " - mptcp: drop skb if MPTCP skb extension allocation fails", " - mptcp: pm: kernel: flush: do not reset ADD_ADDR limit", " - selftests/memfd: add test for mapping write-sealed memfd read-only", " - net: Add net_passive_inc() and net_passive_dec().", " - smb: client: fix netns refcount leak after net_passive changes", " - net_sched: sch_ets: implement lockless ets_dump()", " - leds: flash: leds-qcom-flash: Limit LED current based on thermal", " condition", " - leds: flash: leds-qcom-flash: Fix registry access after re-bind", " - fscrypt: Don't use problematic non-inline crypto engines", " - block: Make REQ_OP_ZONE_FINISH a write operation", " - usb: typec: fusb302: cache PD RX state", " - btrfs: don't ignore inode missing when replaying log tree", " - btrfs: move transaction aborts to the error site in", " add_block_group_free_space()", " - btrfs: always abort transaction on failure to add block group to free", " space tree", " - xfs: fully decouple XFS_IBULK* flags from XFS_IWALK* flags", " - btrfs: fix ssd_spread overallocation", " - btrfs: constify more pointer parameters", " - btrfs: populate otime when logging an inode item", " - btrfs: send: factor out common logic when sending xattrs", " - btrfs: send: only use boolean variables at process_recorded_refs()", " - btrfs: send: add and use helper to rename current inode when processing", " refs", " - btrfs: send: keep the current inode's path cached", " - btrfs: send: avoid path allocation for the current inode when issuing", " commands", " - btrfs: send: use fallocate for hole punching with send stream v2", " - btrfs: send: make fs_path_len() inline and constify its argument", " - wifi: mac80211: check basic rates validity in sta_link_apply_parameters", " - usb: dwc3: imx8mp: fix device leak at unbind", " - ata: Fix SATA_MOBILE_LPM_POLICY description in Kconfig", " - PM: runtime: Take active children into account in", " pm_runtime_get_if_in_use()", " - ata: libata-scsi: Return aborted command when missing sense and result", " TF", " - kbuild: userprogs: use correct linker when mixing clang and GNU ld", " - memstick: Fix deadlock by moving removing flag earlier", " - mmc: sdhci-pci-gli: GL9763e: Rename the gli_set_gl9763e() for", " consistency", " - squashfs: fix memory leak in squashfs_fill_super", " - mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn", " - ALSA: hda/realtek: Add support for HP EliteBook x360 830 G6 and", " EliteBook 830 G6", " - drm/amd/display: Fix fractional fb divider in set_pixel_clock_v3", " - drm/amd/display: Fix DP audio DTO1 clock source on DCE 6.", " - drm/amd/display: Find first CRTC and its line time in", " dce110_fill_display_configs", " - drm/amd/display: Fill display clock and vblank time in", " dce110_fill_display_configs", " - soc: qcom: mdt_loader: Fix error return values in mdt_header_valid()", " - PCI: rockchip: Use standard PCIe definitions", " - PCI: rockchip: Set Target Link Speed to 5.0 GT/s before retraining", " - PCI: imx6: Delay link start until configfs 'start' written", " - PCI: imx6: Add IMX8MM_EP and IMX8MP_EP fixed 256-byte BAR 4 in", " epc_features", " - scsi: mpi3mr: Drop unnecessary volatile from __iomem pointers", " - scsi: mpi3mr: Serialize admin queue BAR writes on 32-bit systems", " - ext4: preserve SB_I_VERSION on remount", " - arm64: dts: ti: k3-am62-main: Remove eMMC High Speed DDR support", " - mptcp: remove duplicate sk_reset_timer call", " - mptcp: disable add_addr retransmission when timeout is 0", " - selftests: mptcp: pm: check flush doesn't reset limits", " - mmc: sdhci-pci-gli: Use PCI AER definitions, not hard-coded values", " - mmc: sdhci-pci-gli: Add a new function to simplify the code", " - cpuidle: menu: Remove iowait influence", " - cpuidle: governors: menu: Avoid selecting states with too much latency", " - fpga: zynq_fpga: Fix the wrong usage of dma_map_sgtable()", " - iio: pressure: bmp280: Use IS_ERR() in bmp280_common_probe()", " - iio: proximity: isl29501: fix buffered read on big-endian systems", " - most: core: Drop device reference after usage in get_channel()", " - cdx: Fix off-by-one error in cdx_rpmsg_probe()", " - usb: quirks: Add DELAY_INIT quick for another SanDisk 3.2Gen1 Flash", " Drive", " - usb: core: hcd: fix accessing unmapped memory in SINGLE_STEP_SET_FEATURE", " test", " - usb: renesas-xhci: Fix External ROM access timeouts", " - USB: storage: Add unusual-devs entry for Novatek NTK96550-based camera", " - usb: storage: realtek_cr: Use correct byte order for bcs->Residue", " - USB: storage: Ignore driver CD mode for Realtek multi-mode Wi-Fi dongles", " - usb: dwc3: Ignore late xferNotReady event to prevent halt timeout", " - usb: dwc3: pci: add support for the Intel Wildcat Lake", " - drm/amd/display: Don't overclock DCE 6 by 15%", " - compiler: remove __ADDRESSABLE_ASM{_STR,}() again", " - mmc: sdhci-pci-gli: GL9763e: Mask the replay timer timeout of AER", " - powerpc/boot: Fix build with gcc 15", " - tracing: Remove unneeded goto out logic", " - iio: temperature: maxim_thermocouple: use DMA-safe buffer for spi_read()", " - iio: imu: inv_icm42600: switch timestamp type from int64_t __aligned(8)", " to aligned_s64", " - iio: imu: inv_icm42600: use = { } instead of memset()", " - iio: imu: inv_icm42600: Convert to uXX and sXX integer types", " - iio: imu: inv_icm42600: change invalid data error to -EBUSY", " - usb: xhci: Fix slot_id resource race conflict", " - usb: typec: maxim_contaminant: re-enable cc toggle if cc is open and", " port is clean", " - usb: typec: maxim_contaminant: disable low power mode when reading", " comparator values", " - spi: spi-fsl-lpspi: Clamp too high speed_hz", " - cgroup/cpuset: Use static_branch_enable_cpuslocked() on", " cpusets_insane_config_key", " - iosys-map: Fix undefined behavior in iosys_map_clear()", " - RDMA/erdma: Fix ignored return value of init_kernel_qp", " - RDMA/bnxt_re: Fix to do SRQ armena by default", " - RDMA/bnxt_re: Fix to remove workload check in SRQ limit path", " - RDMA/bnxt_re: Fix to initialize the PBL array", " - Bluetooth: hci_event: fix MTU for BN == 0 in CIS Established", " - Bluetooth: hci_conn: do return error from hci_enhanced_setup_sync()", " - mlxsw: spectrum: Forward packets with an IPv4 link-local source IP", " - ALSA: usb-audio: Fix size validation in convert_chmap_v3()", " - ipv6: sr: validate HMAC algorithm ID in seg6_hmac_info_add", " - net: ethernet: mtk_ppe: add RCU lock around dev_fill_forward_path", " - phy: mscc: Fix timestamping for vsc8584", " - net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization", " - LoongArch: Optimize module load time by optimizing PLT/GOT counting", " - ixgbe: xsk: resolve the negative overflow of budget in ixgbe_xmit_zc", " - igc: fix disabling L1.2 PCI-E link substate on I226 on init", " - net/sched: Remove unnecessary WARNING condition for empty child qdisc in", " htb_activate", " - bonding: update LACP activity flag after setting lacp_active", " - bonding: Add independent control state machine", " - bonding: send LACPDUs periodically in passive mode after receiving", " partner's LACPDU", " - Octeontx2-af: Skip overlap check for SPI field", " - net/mlx5: Base ECVF devlink port attrs from 0", " - net/mlx5e: Preserve shared buffer capacity during headroom updates", " - ALSA: usb-audio: Use correct sub-type for UAC3 feature unit validation", " - s390/hypfs: Avoid unnecessary ioctl registration in debugfs", " - s390/hypfs: Enable limited access during lockdown", " - alloc_fdtable(): change calling conventions.", " - LoongArch: Avoid in-place string operation on FDT content", " - clk: samsung: gs101: fix CLK_DOUT_CMU_G3D_BUSD", " - mm/memory-tier: fix abstract distance calculation overflow", " - nvme-tcp: log TLS handshake failures at error level", " - ata: ahci: Disallow LPM policy control if not supported", " - ata: ahci: Disable DIPM if host lacks support", " - usb: typec: tcpm/tcpci_maxim: fix irq wake usage", " - pmdomain: ti: Select PM_GENERIC_DOMAINS", " - cpufreq: intel_pstate: Add Granite Rapids support in no-HWP mode", " - platform/chrome: cros_ec_sensorhub: Retries when a sensor is not ready", " - ASoC: SOF: topology: Parse the dapm_widget_tokens in case of DSPless", " mode", " - tty: serial: fix print format specifiers", " - netfilter: nft_set_pipapo: prefer kvmalloc for scratch maps", " - wifi: iwlwifi: mvm: avoid outdated reorder buffer head_sn", " - idpf: preserve coalescing settings across resets", " - wifi: mac80211: don't unreserve never reserved chanctx", " - sched/deadline: Fix accounting after global limits change", " - wifi: mac80211: avoid weird state in error path", " - perf/arm: Add missing .suppress_bind_attrs", " - drm/imagination: Clear runtime PM errors while resetting the GPU", " - drm/xe/xe_query: Use separate iterator while filling GT list", " - wifi: ath12k: Fix station association with MBSSID Non-TX BSS", " - lib: packing: Include necessary headers", " - arm64: stacktrace: Check kretprobe_find_ret_addr() return value", " - net: dsa: b53: ensure BCM5325 PHYs are enabled", " - drm/amd/display: Update DMCUB loading sequence for DCN3.5", " - drm/amd/display: Disable dsc_power_gate for dcn314 by default", " - RDMA/bnxt_re: Fix size of uverbs_copy_to() in", " BNXT_RE_METHOD_GET_TOGGLE_MEM", " - media: ipu-bridge: Add _HID for OV5670", " - scsi: lpfc: Ensure HBA_SETUP flag is used only for SLI4 in", " dev_loss_tmo_callbk", " - media: uvcvideo: Add quirk for HP Webcam HD 2300", " - crypto: ccp - Add missing bootloader info reg for pspv6", " - soundwire: amd: cancel pending slave status handling workqueue during", " remove sequence", " - tools/power turbostat: Fix build with musl", " - tools/power turbostat: Handle cap_get_proc() ENOSYS", " - smb: client: don't call init_waitqueue_head(&info->conn_wait) twice in", " _smbd_get_connection", " - lib/sbitmap: convert shallow_depth from one word to the whole sbitmap", " - drm/amdgpu: fix vram reservation issue", " - btrfs: qgroup: set quota enabled bit if quota disable fails flushing", " reservations", " - btrfs: qgroup: fix qgroup create ioctl returning success after quotas", " disabled", " - btrfs: don't skip remaining extrefs if dir not found during log replay", " - btrfs: error on missing block group when unaccounting log tree extent", " buffers", " - btrfs: fix iteration bug in __qgroup_excl_accounting()", " - xfs: fix scrub trace with null pointer in quotacheck", " - media: v4l2: Add support for NV12M tiled variants to v4l2_format_info()", " - PCI: Store all PCIe Supported Link Speeds", " - PCI: Allow PCI bridges to go to D3Hot on all non-x86", " - PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug Capable ports", " - ata: libata-sata: Add link_power_management_supported sysfs attribute", " - io_uring/rw: cast rw->flags assignment to rwf_t", " - PCI: Honor Max Link Speed when determining supported speeds", " - ACPI: Return -ENODEV from acpi_parse_spcr() when SPCR support is", " disabled", " - crypto: octeontx2 - Fix address alignment issue on ucode loading", " - crypto: octeontx2 - Fix address alignment on CN10K A0/A1 and OcteonTX2", " - crypto: octeontx2 - Fix address alignment on CN10KB and CN10KA-B0", " - btrfs: fix incorrect log message for nobarrier mount option", " - btrfs: restore mount option info messages during mount", " - btrfs: fix printing of mount info messages for NODATACOW/NODATASUM", " - apparmor: Fix 8-byte alignment for initial dfa blob streams", " - PCI/portdrv: Use is_pciehp instead of is_hotplug_bridge", " - PCI: imx6: Remove apps_reset toggling from", " imx_pcie_{assert/deassert}_core_reset", " - amdgpu/amdgpu_discovery: increase timeout limit for IFWI init", " - ASoC: SOF: amd: acp-loader: Use GFP_KERNEL for DMA allocations in resume", " context", " - drm/amdgpu/discovery: fix fw based ip discovery", " - lib/string_choices: Add str_true_false()/str_false_true() helper", " - USB: typec: Use str_enable_disable-like helpers", " - btrfs: qgroup: drop unused parameter fs_info from __del_qgroup_rb()", " - btrfs: explicitly ref count block_group on new_bgs list", " - btrfs: codify pattern for adding block_group to bg_list", " - btrfs: zoned: requeue to unused block group list if zone finish failed", " - drm/vblank: Introduce drm_crtc_vblank_crtc()", " - drm/vblank: add dynamic per-crtc vblank configuration support", " - drm/amd/display: Fix Xorg desktop unresponsive on Replay panel", " - arch: consolidate existing CONFIG_PAGE_SIZE_*KB definitions", " - arch: simplify architecture specific page size configuration", " - [Config] update page size configuration", " - arch: define CONFIG_PAGE_SIZE_*KB on all architectures", " - [Config] update page size on all architectures", " - Mark xe driver as BROKEN if kernel page size is not 4kB", " - [Config] disable xe driver where page size is not 4kB", " - arm64: dts: ti: k3-am6*: Add boot phase flag to support MMC boot", " - arm64: dts: ti: k3-am62*: Add non-removable flag for eMMC", " - arm64: dts: ti: k3-am6*: Add bootph-all property in MMC node", " - arm64: dts: ti: k3-am6*: Remove DLL properties for soft PHYs", " - arm64: dts: ti: k3-am6*: Remove disable-wp for eMMC", " - arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file", " - kcov, usb: Don't disable interrupts in kcov_remote_start_usb_softirq()", " - drm/i915/icl+/tc: Convert AUX powered WARN to a debug message", " - drm/i915/display: add intel_encoder_is_*() and _to_*() functions", " - drm/i915/icl+/tc: Cache the max lane count value", " - ovl: use I_MUTEX_PARENT when locking parent in ovl_create_temp()", " - cgroup/cpuset: Fix a partition error with CPU hotplug", " - drm/tests: Fix endian warning", " - RDMA/bnxt_re: Fix a possible memory leak in the driver", " - RDMA/hns: Fix dip entries leak on devices newer than hip09", " - net: xilinx: axienet: Fix RX skb ring management in DMAengine mode", " - drm/hisilicon/hibmc: refactored struct hibmc_drm_private", " - drm/hisilicon/hibmc: fix the i2c device resource leak when vdac init", " failed", " - drm/amd/display: Don't print errors for nonexistent connectors", " - net: dsa: microchip: Fix KSZ9477 HSR port setup issue", " - net/mlx5: Relocate function declarations from port.h to mlx5_core.h", " - net/mlx5e: Extract checking of FEC support for a link mode", " - net/mlx5e: Support FEC settings for 100G/lane modes", " - net/mlx5: Add IFC bits and enums for buf_ownership", " - net/mlx5e: Query FW for buffer ownership", " - Upstream stable to v6.6.103, v6.12.43, v6.12.44", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39779", " - btrfs: subpage: keep TOWRITE tag until folio is cleaned", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39759", " - btrfs: qgroup: fix race between quota disable and quota rescan ioctl", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39705", " - drm/amd/display: fix a Null pointer dereference vulnerability", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39707", " - drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39712", " - media: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38686", " - userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38703", " - drm/xe: Make dma-fences compliant with the safe access rules", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39746", " - wifi: ath10k: shutdown driver when hardware is unreliable", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39747", " - drm/msm: Add error handling for krealloc in metadata setup", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38704", " - rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer access", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39748", " - bpf: Forget ranges when refining tnum after JSET", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38705", " - drm/amd/pm: fix null pointer access", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38710", " - gfs2: Validate i_depth for exhash directories", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38722", " - habanalabs: fix UAF in export_dmabuf()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38732", " - netfilter: nf_reject: don't leak dst refcount for loopback packets", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39766", " - net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38734", " - net/smc: fix UAF on smcsk after smc_listen_out()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38735", " - gve: prevent ethtool ops after shutdown", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39673", " - ppp: fix race conditions in ppp_fill_forward_path", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39770", " - net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39675", " - drm/amd/display: Add null pointer check in", " mod_hdcp_hdcp1_create_session()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39772", " - drm/hisilicon/hibmc: fix the hibmc loaded failed bug", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38676", " - iommu/amd: Avoid stack buffer overflow from kernel cmdline", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39676", " - scsi: qla4xxx: Prevent a potential error pointer dereference", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39773", " - net: bridge: fix soft lockup in br_multicast_query_expired()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39679", " - drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39681", " - x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39687", " - iio: light: as73211: Ensure buffer holes are zeroed", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39683", " - tracing: Limit access to parser->buffer when trace_get_user failed", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39801", " - usb: dwc3: Remove WARN_ON for device endpoint command timeouts", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39684", " - comedi: Fix use of uninitialized memory in do_insn_ioctl() and", " do_insnlist_ioctl()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39685", " - comedi: pcl726: Prevent invalid irq number", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39686", " - comedi: Make insn_rw_emulate_bits() do insn->n samples", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39689", " - ftrace: Also allocate and copy hash for reading of filter files", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39691", " - fs/buffer: fix use-after-free when call bh_read() helper", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39692", " - smb: server: split ksmbd_rdma_stop_listening() out of", " ksmbd_rdma_destroy()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39788", " - scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39693", " - drm/amd/display: Avoid a NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39694", " - s390/sclp: Fix SCCB present check", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39776", " - mm/debug_vm_pgtable: clear page table entries at destroy_args()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38681", " - mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39800", " - btrfs: abort transaction on unexpected eb generation at", " btrfs_copy_root()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38684", " - net/sched: ets: use old 'nbands' while purging unused classes", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-21884", " - net: better track kernel sockets lifetime", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39701", " - ACPI: pfr_update: Fix the driver update version check", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39702", " - ipv6: sr: Fix MAC comparison to be constant-time", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39703", " - net, hsr: reject HSR frame if skb can't hold tag", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39706", " - drm/amdkfd: Destroy KFD debugfs after destroy KFD wq", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39709", " - media: venus: protect against spurious interrupts during probe", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39710", " - media: venus: Add a check for packet size after reading from shared", " memory", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39711", " - media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable()", " calls", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39713", " - media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39714", " - media: usbtv: Lock resolution while streaming", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39715", " - parisc: Revise gateway LWS calls to probe user read access", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39716", " - parisc: Revise __get_user() to probe user read access", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39781", " - parisc: Drop WARN_ON_ONCE() from flush_cache_vmap", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39782", " - jbd2: prevent softlockup in jbd2_log_do_checkpoint()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38677", " - f2fs: fix to avoid out-of-boundary access in dnode page", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39718", " - vsock/virtio: Validate length in packet header before skb_put()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39783", " - PCI: endpoint: Fix configfs group list head handling", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39719", " - iio: imu: bno055: fix OOB access of hw_xlate array", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39787", " - soc: qcom: mdt_loader: Ensure we don't read past the ELF header", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39720", " - ksmbd: fix refcount leak causing resource not released", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39721", " - crypto: qat - flush misc workqueue during device shutdown", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39790", " - bus: mhi: host: Detect events pointing to unexpected TREs", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39724", " - serial: 8250: fix panic due to PSLVERR", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39758", " - RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38679", " - media: venus: Fix OOB read due to missing payload bound check", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38680", " - media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39736", " - mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39737", " - mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38683", " - hv_netvsc: Fix panic during namespace deletion with VF", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38685", " - fbdev: Fix vmalloc out-of-bounds write in fast_imageblit", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39738", " - btrfs: do not allow relocation of partially dropped subvolumes", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38687", " - comedi: fix race between polling and detaching", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39760", " - usb: core: config: Prevent OOB read in SS endpoint companion parsing", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38688", " - iommufd: Prevent ALIGN() overflow", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39739", " - iommu/arm-smmu-qcom: Add SM6115 MDSS compatible", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38691", " - pNFS: Fix uninited ptr deref in block/scsi layout", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39795", " - block: avoid possible overflow for chunk_sectors check in", " blk_stack_limits()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38692", " - exfat: add cluster chain loop check for dir", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38693", " - media: dvb-frontends: w7090p: fix null-ptr-deref in", " w7090p_tuner_write_serpar and w7090p_tuner_read_serpar", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38694", " - media: dvb-frontends: dib7090p: fix null-ptr-deref in", " dib7090p_rw_on_apb()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38695", " - scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport", " structure", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39742", " - RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38696", " - MIPS: Don't crash in stack_top() for tasks without ABI or vDSO", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38697", " - jfs: upper bound check of tree index in dbAllocAG", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38698", " - jfs: Regular file corruption check", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39743", " - jfs: truncate good inode pages when hard link is 0", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38699", " - scsi: bfa: Double-free fix", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38700", " - scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is", " allocated", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38701", " - ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38702", " - fbdev: fix potential buffer overflow in do_register_framebuffer()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39744", " - rcu: Fix rcu_read_unlock() deadloop due to IRQ work", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39761", " - wifi: ath12k: Decrement TID on RX peer frag setup error handling", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39797", " - xfrm: Duplicate SPI Handling", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39749", " - rcu: Protect ->defer_qs_iw_pending from data race", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39750", " - wifi: ath12k: Correct tid cleanup when tid setup fails", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38706", " - ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39794", " - ARM: tegra: Use I/O memcpy to write to IRAM", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39752", " - ARM: rockchip: fix kernel hang during smp initialization", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39763", " - ACPI: APEI: send SIGBUS to current task if synchronous memory error not", " recovered", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38707", " - fs/ntfs3: Add sanity check for file name", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38708", " - drbd: add missing kref_get in handle_write_conflicts", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39753", " - gfs2: Set .migrate_folio in gfs2_{rgrp,meta}_aops", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38711", " - smb/server: avoid deadlock when linking with ReplaceIfExists", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38712", " - hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38713", " - hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38714", " - hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38715", " - hfs: fix slab-out-of-bounds in hfs_bnode_read()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38716", " - hfs: fix general protection fault in hfs_find_init()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38718", " - sctp: linearize cloned gso packets in sctp_rcv", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38721", " - netfilter: ctnetlink: fix refcount leak on table dump", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38614", " - eventpoll: Fix semi-unbounded recursion", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39756", " - fs: Prevent file descriptor table allocations exceeding INT_MAX", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39798", " - NFS: Fix the setting of capabilities when automounting a new filesystem", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38724", " - nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38730", " - io_uring/net: commit partial buffers on retry", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38725", " - net: usb: asix_devices: add phy_mask for ax88772 mdio bus", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38728", " - smb3: fix for slab out of bounds on mount to ksmbd", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-39757", " - ALSA: usb-audio: Validate UAC3 cluster segment descriptors", "", " * Noble update: upstream stable patchset 2026-01-06 (LP: #2137586) //", " CVE-2025-38729", " - ALSA: usb-audio: Validate UAC3 power domain descriptors, too", "", " * CVE-2025-40297", " - net: bridge: fix use-after-free due to MST port state bypass", "", " * CVE-2025-40256", " - xfrm: also call xfrm_state_delete_tunnel at destroy time for states that", " were never added", "", " * CVE-2025-40215", " - xfrm: delete x->tunnel as we delete x", "", " * CVE-2025-40214", " - af_unix: Initialise scc_index in unix_add_edge().", "", " * CVE-2025-38248", " - bridge: mcast: Fix use-after-free during router port configuration", "", " * Enabling crypto selftests causes boot stall on 6.8 (LP: #2135716)", " - SAUCE: Revert \"crypto: api - Fix boot-up self-test race\"", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261)", " - ASoC: fsl_asrc: use internal measured ratio for non-ideal ratio mode", " - perf/core: Fix the WARN_ON_ONCE is out of lock protected region", " - ASoC: cs35l56: probe() should fail if the device ID is not recognized", " - Bluetooth: hci_sync: Fix not disabling advertising instance", " - Bluetooth: hci_event: Fix not marking Broadcast Sink BIS as connected", " - pinctrl: amd: Clear GPIO debounce for suspend", " - fix proc_sys_compare() handling of in-lookup dentries", " - vsock: fix `vsock_proto` declaration", " - vsock: Fix IOCTL_VM_SOCKETS_GET_LOCAL_CID to check also", " `transport_local`", " - net: stmmac: Fix interrupt handling for level-triggered mode in", " DWC_XGMAC2", " - net: phy: smsc: Fix Auto-MDIX configuration when disabled by strap", " - net: phy: smsc: Force predictable MDI-X state on LAN87xx", " - net: phy: smsc: Fix link failure in forced mode with Auto-MDIX", " - perf: build: Setup PKG_CONFIG_LIBDIR for cross compilation", " - x86/mce/amd: Add default names for MCA banks and blocks", " - x86/mce/amd: Fix threshold limit reset", " - x86/mce: Don't remove sysfs if thresholding sysfs init fails", " - x86/mce: Make sure CMCI banks are cleared during shutdown on Intel", " - KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing", " table.", " - gre: Fix IPv6 multicast route creation.", " - md/md-bitmap: fix GPF in bitmap_get_stats()", " - drm/ttm: fix error handling in ttm_buffer_object_transfer", " - drm/gem: Fix race in drm_gem_handle_create_tail()", " - Revert \"usb: gadget: u_serial: Add null pointer check in gs_start_io\"", " - drm/framebuffer: Acquire internal references on GEM handles", " - kallsyms: fix build without execinfo", " - maple_tree: fix mt_destroy_walk() on root leaf node", " - mm: fix the inaccurate memory statistics issue for users", " - scripts/gdb: fix interrupts display after MCP on x86", " - scripts/gdb: de-reference per-CPU MCE interrupts", " - scripts/gdb: fix interrupts.py after maple tree conversion", " - mm/vmalloc: leave lazy MMU mode on PTE mapping error", " - pwm: mediatek: Ensure to disable clocks in error path", " - x86/rdrand: Disable RDSEED on AMD Cyan Skillfish", " - x86/mm: Disable hugetlb page table sharing on 32-bit", " - smb: server: make use of rdma_destroy_qp()", " - ksmbd: fix a mount write count leak in ksmbd_vfs_kern_path_locked()", " - erofs: fix to add missing tracepoint in erofs_read_folio()", " - netlink: Fix rmem check in netlink_broadcast_deliver().", " - netlink: make sure we allow at least one dump skb", " - smb: client: avoid unnecessary reconnects when refreshing referrals", " - smb: client: fix DFS interlink failover", " - cifs: all initializations for tcon should happen in tcon_info_alloc", " - ibmvnic: Fix hardcoded NUM_RX_STATS/NUM_TX_STATS with dynamic sizeof", " - net: phy: microchip: limit 100M workaround to link-down events on", " LAN88xx", " - can: m_can: m_can_handle_lost_msg(): downgrade msg lost in rx message to", " debug level", " - net: ll_temac: Fix missing tx_pending check in ethtools_set_ringparam()", " - bnxt_en: Fix DCB ETS validation", " - ublk: sanity check add_dev input for underflow", " - atm: idt77252: Add missing `dma_map_error()`", " - um: vector: Reduce stack usage in vector_eth_configure()", " - io_uring: make fallocate be hashed work", " - ASoC: amd: yc: add quirk for Acer Nitro ANV15-41 internal mic", " - ALSA: hda/realtek - Enable mute LED on HP Pavilion Laptop 15-eg100", " - net: usb: qmi_wwan: add SIMCom 8230C composition", " - HID: lenovo: Add support for ThinkPad X1 Tablet Thin Keyboard Gen2", " - net: mana: Record doorbell physical address in PF mode", " - vt: add missing notification when switching back to text mode", " - bpf: Adjust free target to avoid global starvation of LRU map", " - HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY", " - selftests/bpf: adapt one more case in test_lru_map to the new", " target_free", " - smb: client: fix potential race in cifs_put_tcon()", " - drm/amdgpu/discovery: use specific ip_discovery.bin for legacy asics", " - drm/amdgpu/ip_discovery: add missing ip_discovery fw", " - x86/mce: Ensure user polling settings are honored when restarting timer", " - ASoC: fsl_sai: Force a software reset when starting in consumer mode", " - wifi: mt76: mt7921: prevent decap offload config before STA", " initialization", " - wifi: mt76: mt7925: fix the wrong config for tx interrupt", " - wifi: mt76: mt7925: fix invalid array index in ssid assignment during hw", " scan", " - drm/xe: Allocate PF queue size on pow2 boundary", " - clk: scmi: Handle case where child clocks are initialized before their", " parents", " - erofs: address D-cache aliasing", " - wifi: cfg80211/mac80211: correctly parse S1G beacon optional elements", " - wifi: cfg80211: fix S1G beacon head validation in nl80211", " - wifi: mac80211: correctly identify S1G short beacon", " - wifi: mac80211: fix non-transmitted BSSID profile search", " - drm/nouveau/gsp: fix potential leak of memory used during acpi init", " - erofs: free pclusters if no cached folio is attached", " - erofs: get rid of `z_erofs_next_pcluster_t`", " - erofs: tidy up zdata.c", " - erofs: refine readahead tracepoint", " - erofs: fix to add missing tracepoint in erofs_readahead()", " - net: phy: microchip: Use genphy_soft_reset() to purge stale LPA bits", " - selftests: net: lib: Move logging from forwarding/lib.sh here", " - selftests: net: lib: fix shift count out of range", " - net/mlx5e: Add new prio for promiscuous mode", " - ALSA: hda/realtek: Add mic-mute LED setup for ASUS UM5606", " - ALSA: hda/realtek: Add quirks for some Clevo laptops", " - riscv: vdso: Exclude .rodata from the PT_DYNAMIC segment", " - erofs: fix rare pcluster memory leak after unmounting", " - net: libwx: fix alloc msix vectors failed", " - net: wangxun: revert the adjustment of the IRQ vector sequence", " - arm64: Filter out SME hwcaps when FEAT_SME isn't implemented", " - KVM: SVM: Set synthesized TSA CPUID flags", " - Upstream stable to v6.6.98, v6.6.99, v6.12.38, v6.12.39", " - SAUCE: selftests: net: altnames.sh fix following upstream updates", "", " * vrf_route_leaking.sh in net from ubuntu_kernel_selftests linux ADT test", " failure with linux/5.11.0-18.19 (Ping received ICMP Packet too big)", " (LP: #1928890)", " - selftests: net: use slowwait to stabilize vrf_route_leaking test", "", " * ubuntu_bpf failed to build on Noble ( error: ‘struct prog_test_def’ has no", " member named ‘should_tmon’) (LP: #2112357)", " - selftests/bpf: Factor out get_xlated_program() helper", " - selftests/bpf: extract utility function for BPF disassembly", " - selftests/bpf: Add traffic monitor functions.", " - selftests/bpf: Add the traffic monitor option to test_progs.", "", " * ipsec_offload in rtnetlink.sh from ubunsu_kselftests_net fails on O/J", " (LP: #2096976)", " - netdevsim: fix rtnetlink.sh selftest", " - [SAUCE] Fix selftest/net/rtnetlink.sh for Big Endian", "", " * fib_tests.sh in ubuntu_kernel_selftests failed with IPv4 mangling tests", " Connection check - server side (LP: #2012859)", " - selftests: rtnetlink: correct error message in rtnetlink.sh fou test", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740)", " - ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx", " - ethernet: intel: fix building with large NR_CPUS", " - ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx", " - ASoC: Intel: fix SND_SOC_SOF dependencies", " - ASoC: amd: yc: add DMI quirk for ASUS M6501RM", " - audit,module: restore audit logging in load failure case", " - fs_context: fix parameter name in infofc() macro", " - ublk: use vmalloc for ublk_device's __queues", " - hfsplus: make splice write available again", " - hfs: make splice write available again", " - ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask()", " - ASoC: ops: dynamically allocate struct snd_ctl_elem_value", " - ASoC: mediatek: use reserved memory or enable buffer pre-allocation", " - selftests: Fix errno checking in syscall_user_dispatch test", " - soc: qcom: QMI encoding/decoding for big endian", " - arm64: dts: qcom: sdm845: Expand IMEM region", " - arm64: dts: qcom: sc7180: Expand IMEM region", " - arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely", " - ARM: dts: vfxxx: Correctly use two tuples for timer address", " - usb: host: xhci-plat: fix incorrect type for of_match variable in", " xhci_plat_probe()", " - usb: misc: apple-mfi-fastcharge: Make power supply names unique", " - vmci: Prevent the dispatching of uninitialized payloads", " - pps: fix poll support", " - Revert \"vmci: Prevent the dispatching of uninitialized payloads\"", " - usb: early: xhci-dbc: Fix early_ioremap leak", " - arm: dts: ti: omap: Fixup pinheader typo", " - soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS", " - ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface", " - arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed", " - arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speed", " - cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode", " - cpufreq: Initialize cpufreq-based frequency-invariance later", " - cpufreq: Init policy->rwsem before it may be possibly used", " - samples: mei: Fix building on musl libc", " - soc: qcom: pmic_glink: fix OF node leak", " - interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg", " - interconnect: qcom: sc8180x: specify num_nodes", " - staging: nvec: Fix incorrect null termination of battery manufacturer", " - drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed", " - bpf, sockmap: Fix psock incorrectly pointing to sk", " - selftests/bpf: fix signedness bug in redir_partial()", " - net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain", " - drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel", " - bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure", " - caif: reduce stack size, again", " - wifi: iwlwifi: Fix memory leak in iwl_mvm_init()", " - tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range", " - net: dst: annotate data-races around dst->input", " - net: dst: annotate data-races around dst->output", " - kselftest/arm64: Fix check for setting new VLs in sve-ptrace", " - drm/msm/dpu: Fill in min_prefill_lines for SC8180X", " - m68k: Don't unregister boot console needlessly", " - drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value", " - sched/psi: Optimize psi_group_change() cpu_clock() usage", " - fbcon: Fix outdated registered_fb reference in comment", " - netfilter: nf_tables: Drop dead code from fill_*_info routines", " - netfilter: nf_tables: adjust lockdep assertions handling", " - arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX", " - um: rtc: Avoid shadowing err in uml_rtc_start()", " - net_sched: act_ctinfo: use atomic64_t for three counters", " - xen/gntdev: remove struct gntdev_copy_batch from stack", " - tcp: call tcp_measure_rcv_mss() for ooo packets", " - wifi: rtl8xxxu: Fix RX skb size for aggregation disabled", " - mwl8k: Add missing check after DMA map", " - iommu/amd: Fix geometry.aperture_end for V2 tables", " - wifi: plfxlc: Fix error handling in usb driver probe", " - wifi: mac80211: Do not schedule stopped TXQs", " - wifi: mac80211: Don't call fq_flow_idx() for management frames", " - wifi: mac80211: Check 802.11 encaps offloading in", " ieee80211_tx_h_select_key()", " - Reapply \"wifi: mac80211: Update skb's control block key in", " ieee80211_tx_dequeue()\"", " - wifi: ath12k: fix endianness handling while accessing wmi service bit", " - wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P", " IE", " - wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon()", " - kcsan: test: Initialize dummy variable", " - Bluetooth: hci_event: Mask data status from LE ext adv reports", " - tools/rv: Do not skip idle in trace", " - can: peak_usb: fix USB FD devices potential malfunction", " - can: kvaser_pciefd: Store device channel index", " - can: kvaser_usb: Assign netdev.dev_port based on device channel index", " - net/mlx5e: Clear Read-Only port buffer size in PBMC before update", " - selftests: rtnetlink.sh: remove esp4_offload after test", " - vrf: Drop existing dst reference in vrf_ip6_input_dst", " - ipv6: annotate data-races around rt->fib6_nsiblings", " - bpf/preload: Don't select USERMODE_DRIVER", " - PCI: rockchip-host: Fix \"Unexpected Completion\" log message", " - crypto: sun8i-ce - fix nents passed to dma_unmap_sg()", " - crypto: qat - use unmanaged allocation for dc_data", " - crypto: marvell/cesa - Fix engine load inaccuracy", " - mtd: fix possible integer overflow in erase_xfer()", " - media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check", " - power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set", " - crypto: arm/aes-neonbs - work around gcc-15 warning", " - PCI: endpoint: pci-epf-vntb: Return -ENOENT if", " pci_epc_get_next_free_bar() fails", " - pinctrl: sunxi: Fix memory leak on krealloc failure", " - fanotify: sanitize handle_type values when reporting fid", " - clk: clk-axi-clkgen: fix fpfd_max frequency for zynq", " - Fix dma_unmap_sg() nents value", " - perf tools: Fix use-after-free in help_unknown_cmd()", " - perf sched: Free thread->priv using priv_destructor", " - perf sched: Fix memory leaks for evsel->priv in timehist", " - perf sched: Fix memory leaks in 'perf sched latency'", " - crypto: inside-secure - Fix `dma_unmap_sg()` nents value", " - RDMA/hns: Fix -Wframe-larger-than issue", " - kernel: trace: preemptirq_delay_test: use offstack cpu mask", " - perf tests bp_account: Fix leaked file descriptor", " - clk: sunxi-ng: v3s: Fix de clock definition", " - scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value", " - scsi: elx: efct: Fix dma_unmap_sg() nents value", " - scsi: mvsas: Fix dma_unmap_sg() nents value", " - scsi: isci: Fix dma_unmap_sg() nents value", " - watchdog: ziirave_wdt: check record length in ziirave_firm_verify()", " - hwrng: mtk - handle devm_pm_runtime_enable errors", " - crypto: keembay - Fix dma_unmap_sg() nents value", " - crypto: img-hash - Fix dma_unmap_sg() nents value", " - soundwire: stream: restore params when prepare ports fail", " - PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem", " attribute", " - fs/orangefs: Allow 2 more characters in do_c_string()", " - dmaengine: mv_xor: Fix missing check after DMA map and missing unmap", " - dmaengine: nbpfaxi: Add missing check after DMA map", " - ASoC: fsl_xcvr: get channel status data when PHY is not exists", " - sh: Do not use hyphen in exported variable name", " - perf tools: Remove libtraceevent in .gitignore", " - crypto: qat - fix DMA direction for compression on GEN2 devices", " - crypto: qat - fix seq_file position update in adf_ring_next()", " - jfs: fix metapage reference count leak in dbAllocCtl", " - mtd: rawnand: atmel: Fix dma_mapping_error() address", " - mtd: rawnand: rockchip: Add missing check after DMA map", " - mtd: rawnand: atmel: set pmecc data setup time", " - vhost-scsi: Fix log flooding with target does not exist errors", " - bpf: Check flow_dissector ctx accesses are aligned", " - bpf: Check netfilter ctx accesses are aligned", " - apparmor: ensure WB_HISTORY_SIZE value is a power of 2", " - apparmor: fix loop detection used in conflicting attachment resolution", " - module: Restore the moduleparam prefix length check", " - ucount: fix atomic_long_inc_below() argument type", " - rtc: ds1307: fix incorrect maximum clock rate handling", " - rtc: hym8563: fix incorrect maximum clock rate handling", " - rtc: nct3018y: fix incorrect maximum clock rate handling", " - rtc: pcf85063: fix incorrect maximum clock rate handling", " - rtc: pcf8563: fix incorrect maximum clock rate handling", " - rtc: rv3028: fix incorrect maximum clock rate handling", " - f2fs: doc: fix wrong quota mount option description", " - f2fs: fix to update upper_p in __get_secs_required() correctly", " - f2fs: fix to calculate dirty data during has_not_enough_free_secs()", " - vfio: Fix unbalanced vfio_df_close call in no-iommu mode", " - vfio: Prevent open_count decrement to negative", " - vfio/pci: Separate SR-IOV VF dev_set", " - scsi: mpt3sas: Fix a fw_event memory leak", " - scsi: Revert \"scsi: iscsi: Fix HW conn removal use after free\"", " - scsi: ufs: core: Use link recovery when h8 exit fails during runtime", " resume", " - scsi: sd: Make sd shutdown issue START STOP UNIT appropriately", " - kconfig: qconf: fix ConfigList::updateListAllforAll()", " - sched/psi: Fix psi_seq initialization", " - PCI: pnv_php: Work around switches with broken presence detection", " - powerpc/eeh: Export eeh_unfreeze_pe()", " - pNFS/flexfiles: don't attempt pnfs on fatal DS errors", " - sched: Add test_and_clear_wake_up_bit() and atomic_dec_and_wake_up()", " - NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate()", " - NFSv4.2: another fix for listxattr", " - NFS: Fixup allocation flags for nfsiod's __GFP_NORETRY", " - md/md-cluster: handle REMOVE message earlier", " - netpoll: prevent hanging NAPI when netcons gets enabled", " - phy: mscc: Fix parsing of unicast frames", " - net: ipa: add IPA v5.1 and v5.5 to ipa_version_string()", " - netlink: specs: ethtool: fix module EEPROM input/output arguments", " - net/mlx5: Correctly set gso_segs when LRO is used", " - net/sched: taprio: enforce minimum value for picos_per_byte", " - benet: fix BUG when creating VFs", " - irqchip: Build IMX_MU_MSI only on ARM", " - ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out()", " - smb: server: remove separate empty_recvmsg_queue", " - smb: server: make sure we call ib_dma_unmap_single() only if we called", " ib_dma_map_single already", " - smb: server: let recv_done() consistently call", " put_recvmsg/smb_direct_disconnect_rdma_connection", " - smb: server: let recv_done() avoid touching data_transfer after", " cleanup/move", " - smb: client: Use min() macro", " - smb: client: Correct typos in multiple comments across various files", " - smb: smbdirect: add smbdirect_socket.h", " - smb: client: make use of common smbdirect_socket", " - smb: client: make sure we call ib_dma_unmap_single() only if we called", " ib_dma_map_single already", " - smb: client: let recv_done() cleanup before notifying the callers.", " - pptp: fix pptp_xmit() error path", " - smb: client: return an error if rdma_connect does not return within 5", " seconds", " - selftests/perf_events: Add a mmap() correctness test", " - ksmbd: fix corrupted mtime and ctime in smb2_open", " - smb: server: Fix extension string in ksmbd_extract_shortname()", " - USB: serial: option: add Foxconn T99W709", " - Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano", " - net: usbnet: Avoid potential RCU stall on LINK_CHANGE event", " - net: usbnet: Fix the wrong netif_carrier_on() call", " - ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe()", " - ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx()", " - x86/fpu: Delay instruction pointer fixup until after warning", " - MIPS: mm: tlb-r4k: Uniquify TLB entries on init", " - mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery", " - ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX", " - arm64: dts: exynos: gs101: Add 'local-timer-stop' to cpuidle nodes", " - arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size", " - mei: vsc: Destroy mutex after freeing the IRQ", " - mei: vsc: Event notifier fixes", " - mei: vsc: Unset the event callback on remove and probe errors", " - arm64: dts: st: fix timer used for ticks", " - selftests: breakpoints: use suspend_stats to reliably check suspend", " success", " - PM / devfreq: Fix a index typo in trans_stat", " - drm/panfrost: Fix panfrost device variable name in devfreq", " - selftests/bpf: Fix unintentional switch case fall through", " - drm/amdgpu: Remove nbiov7.9 replay count reporting", " - bpf: Ensure RCU lock is held around bpf_prog_ksym_find", " - refscale: Check that nreaders and loops multiplication doesn't overflow", " - iommu/amd: Enable PASID and ATS capabilities in the correct order", " - file: add take_fd() cleanup helper", " - file: fix typo in take_fd() comment", " - rcu: Fix delayed execution of hurry callbacks", " - ring-buffer: Remove ring_buffer_read_prepare_sync()", " - net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863", " - stmmac: xsk: fix negative overflow of budget in zerocopy mode", " - pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state()", " - dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning", " - phy: qualcomm: phy-qcom-eusb2-repeater: Don't zero-out registers", " - perf dso: Add missed dso__put to dso__load_kcore", " - mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER", " - perf sched: Make sure it frees the usage string", " - perf sched: Fix memory leaks in 'perf sched map'", " - perf sched: Use RC_CHK_EQUAL() to compare pointers", " - RDMA/hns: Fix HW configurations not cleared in error flow", " - RDMA/hns: Get message length of ack_req from FW", " - RDMA/hns: Add mutex_destroy()", " - RDMA/hns: Fix accessing uninitialized resources", " - RDMA/hns: Drop GFP_NOWARN", " - crypto: qat - disable ZUC-256 capability for QAT GEN5", " - remoteproc: xlnx: Disable unsupported features", " - perf record: Cache build-ID of hit DSOs only", " - vdpa: Fix IDR memory leak in VDUSE module exit", " - vhost: Reintroduce kthread API and add mode selection", " - [Config] enable VHOST_ENABLE_FORK_OWNER_CONTROL", " - apparmor: Fix unaligned memory accesses in KUnit test", " - f2fs: turn off one_time when forcibly set to foreground GC", " - exfat: fdatasync flag should be same like generic_write_sync()", " - s390/ap: Unmask SLCF bit in card and queue ap functions sysfs", " - block: Fix default IO priority if there is no IO context", " - ASoC: tas2781: Fix the wrong step for TLV on tas2781", " - s390/mm: Allocate page table with PAGE_SIZE granularity", " - smb: client: remove separate empty_packet_queue", " - smb: client: let recv_done() avoid touching data_transfer after", " cleanup/move", " - drm/i915/ddi: change intel_ddi_init_{dp, hdmi}_connector() return type", " - drm/i915/hdmi: propagate errors from intel_hdmi_init_connector()", " - drm/i915/hdmi: add error handling in g4x_hdmi_init()", " - drm/i915/ddi: gracefully handle errors from", " intel_ddi_init_hdmi_connector()", " - drm/i915/display: add intel_encoder_is_hdmi()", " - drm/i915/ddi: only call shutdown hooks for valid encoders", " - PCI/ASPM: Save parent L1SS config in pci_save_aspm_l1ss_state()", " - PCI/ASPM: Fix L1SS saving", " - ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx", " - ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx", " - ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26)", " - s390/mm: Remove possible false-positive warning in pte_free_defer()", " - Upstream stable to v6.6.102, v6.12.42", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38619", " - media: ti: j721e-csi2rx: fix list_del corruption", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38582", " - RDMA/hns: Fix double destruction of rsv_qp", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38585", " - staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38593", " - Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-39732", " - wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38595", " - xen: fix UAF in dmabuf_exp_from_pages()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38660", " - parse_longname(): strrchr() expects NUL-terminated string", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38555", " - usb: gadget : fix use-after-free in composite_dev_cleanup()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2024-36331 // CVE-2025-38560", " - x86/sev: Evict cache lines during SNP memory validation", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38501", " - ksmbd: limit repeated connections from clients with the same IP", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38562", " - ksmbd: fix null pointer dereference error in generate_encryptionkey", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38566", " - sunrpc: fix handling of server side tls alerts", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38568", " - net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38571", " - sunrpc: fix client side handling of tls alerts", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38622", " - net: drop UFO packets in udp_rcv_segment()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38572", " - ipv6: reject malicious packets in ipv6_gso_segment()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38574", " - pptp: ensure minimal skb length in pptp_xmit()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-39730", " - NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38623", " - PCI: pnv_php: Fix surprise plug detection and recovery", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38576", " - powerpc/eeh: Make EEH driver device hotplug safe", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38624", " - PCI: pnv_php: Clean up allocated IRQs on unplug", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38625", " - vfio/pds: Fix missing detach_ioas op", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38626", " - f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-39731", " - f2fs: vm_unmap_ram() may be called from an invalid context", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38652", " - f2fs: fix to avoid out-of-boundary access in devs.path", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38577", " - f2fs: fix to avoid panic in f2fs_evict_inode", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38578", " - f2fs: fix to avoid UAF in f2fs_sync_inode_meta()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38579", " - f2fs: fix KMSAN uninit-value in extent_info usage", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38630", " - fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38632", " - pinmux: fix race causing mux_owner NULL with active mux_usecount", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38653", " - proc: use the same treatment to check proc_lseek as ones for", " proc_read_iter et.al", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38581", " - crypto: ccp - Fix crash when rebind ccp device for ccp.ko", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38634", " - power: supply: cpcap-charger: Fix null check for", " power_supply_get_by_name", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38583", " - clk: xilinx: vcu: unregister pll_post only if registered correctly", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38635", " - clk: davinci: Add NULL check in davinci_lpsc_clk_register()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38587", " - ipv6: fix possible infinite loop in fib6_info_uses_dev()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38588", " - ipv6: prevent infinite loop in rt6_nlmsg_size()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38590", " - net/mlx5e: Remove skb secpath if xfrm state is not found", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38639", " - netfilter: xt_nfacct: don't assume acct name is null-terminated", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38640", " - bpf: Disable migration in nf_hook_run_bpf().", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38644", " - wifi: mac80211: reject TDLS operations when station is not associated", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38553", " - net/sched: Restrict conditions for adding duplicating netems to qdisc", " tree", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38645", " - net/mlx5: Check device memory pointer before usage", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38601", " - wifi: ath11k: clear initialized flag for deinit-ed srng lists", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38602", " - iwlwifi: Add missing check for alloc_ordered_workqueue", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38604", " - wifi: rtl818x: Kill URBs before clearing tx status queue", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38646", " - wifi: rtw89: avoid NULL dereference when RX problematic packet on", " unsupported 6 GHz band", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38608", " - bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38609", " - PM / devfreq: Check governor before using governor->name", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38610", " - powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38612", " - staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38648", " - spi: stm32: Check for cfg availability in stm32_spi_probe", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38659", " - gfs2: No more self recovery", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-39734", " - Revert \"fs/ntfs3: Replace inode_trylock with inode_lock\"", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38650", " - hfsplus: remove mutex_lock check in hfsplus_free_extents", "", " * Noble update: upstream stable patchset 2025-12-17 (LP: #2136740) //", " CVE-2025-38615", " - fs/ntfs3: cancle set bad inode after removing name fails", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361)", " - virtio_ring: Fix error reporting in virtqueue_resize", " - RDMA/core: Rate limit GID cache warning messages", " - interconnect: qcom: sc7280: Add missing num_links to xm_pcie3_1 node", " - iio: adc: ad7949: use spi_is_bpw_supported()", " - regmap: fix potential memory leak of regmap_bus", " - x86/hyperv: Fix usage of cpu_online_mask to get valid cpu", " - platform/x86: Fix initialization order for firmware_attributes_class", " - staging: vchiq_arm: Make vchiq_shutdown never fail", " - net/mlx5: Fix memory leak in cmd_exec()", " - net/mlx5: E-Switch, Fix peer miss rules to use peer eswitch", " - i40e: report VF tx_dropped with tx_errors instead of tx_discards", " - i40e: When removing VF MAC filters, only check PF-set MAC", " - drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe()", " - net: hns3: fix concurrent setting vlan filter issue", " - net: hns3: disable interrupt when ptp init failed", " - net: hns3: fixed vf get max channels bug", " - net: hns3: default enable tx bounce buffer when smmu enabled", " - platform/x86: ideapad-laptop: Fix kbd backlight not remembered among", " boots", " - i2c: tegra: Fix reset error handling with ACPI", " - i2c: virtio: Avoid hang by using interruptible completion wait", " - bus: fsl-mc: Fix potential double device reference in", " fsl_mc_get_endpoint()", " - sprintf.h requires stdarg.h", " - ALSA: hda/realtek - Add mute LED support for HP Pavilion 15-eg0xxx", " - dpaa2-eth: Fix device reference count leak in MAC endpoint handling", " - dpaa2-switch: Fix device reference count leak in MAC endpoint handling", " - e1000e: disregard NVM checksum on tgp when valid checksum bit is not set", " - e1000e: ignore uninitialized checksum word on tgp", " - gve: Fix stuck TX queue for DQ queue format", " - kasan: use vmalloc_dump_obj() for vmalloc error reports", " - resource: fix false warning in __request_region()", " - selftests: mptcp: connect: also cover alt modes", " - selftests: mptcp: connect: also cover checksum", " - mm/zsmalloc: do not pass __GFP_MOVABLE if CONFIG_COMPACTION=n", " - usb: typec: tcpm: allow to use sink in accessory mode", " - usb: typec: tcpm: allow switching to mode accessory to mux properly", " - usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach", " - comedi: comedi_test: Fix possible deletion of uninitialized timers", " - ALSA: hda/tegra: Add Tegra264 support", " - ALSA: hda: Add missing NVIDIA HDA codec IDs", " - drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x", " - mm: khugepaged: fix call hpage_collapse_scan_file() for anonymous vma", " - crypto: powerpc/poly1305 - add depends on BROKEN for now", " - [Config] disable CRYPTO_POLY1305_P10", " - iio: hid-sensor-prox: Fix incorrect OFFSET calculation", " - iio: hid-sensor-prox: Restore lost scale assignments", " - mtd: rawnand: qcom: Fix last codeword read in", " qcom_param_page_type_exec()", " - ksmbd: add free_transport ops in ksmbd connection", " - arm64/cpufeatures/kvm: Add ARMv8.9 FEAT_ECBHB bits in ID_AA64MMFR1", " register", " - ARM: 9448/1: Use an absolute path to unified.h in KBUILD_AFLAGS", " - Revert \"selftests/bpf: Add a cgroup prog bpf_get_ns_current_pid_tgid()", " test\"", " - x86/traps: Initialize DR7 by writing its architectural reset value", " - virtio_net: Enforce minimum TX ring size for reliability", " - platform/x86: asus-nb-wmi: add DMI quirk for ASUS Zenbook Duo UX8406CA", " - platform/mellanox: mlxbf-pmc: Remove newline char from event name input", " - platform/mellanox: mlxbf-pmc: Validate event/enable input", " - platform/mellanox: mlxbf-pmc: Use kstrtobool() to check 0/1 input", " - xfrm: state: use a consistent pcpu_id in xfrm_state_find", " - xfrm: Set transport header to fix UDP GRO handling", " - ALSA: hda/realtek: Fix mute LED mask on HP OMEN 16 laptop", " - drm/sched: Remove optimization that causes hang when killing dependent", " jobs", " - mm/ksm: fix -Wsometimes-uninitialized from clang-21 in", " advisor_mode_show()", " - ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa0xxx", " - rust: give Clippy the minimum supported Rust version", " - selftests/bpf: Add tests with stack ptr register in conditional jmp", " - spi: cadence-quadspi: fix cleanup of rx_chan on failure paths", " - ext4: don't explicit update times in ext4_fallocate()", " - ext4: refactor ext4_punch_hole()", " - ext4: refactor ext4_zero_range()", " - ext4: refactor ext4_collapse_range()", " - ext4: refactor ext4_insert_range()", " - ext4: factor out ext4_do_fallocate()", " - ext4: move out inode_lock into ext4_fallocate()", " - fs: sort out the fallocate mode vs flag mess", " - ext4: move out common parts into ext4_fallocate()", " - ext4: fix incorrect punch max_end", " - ext4: correct the error handle in ext4_fallocate()", " - ext4: fix out of bounds punch offset", " - KVM: x86: drop x86.h include from cpuid.h", " - KVM: x86: Route non-canonical checks in emulator through emulate_ops", " - KVM: x86: Add X86EMUL_F_MSR and X86EMUL_F_DT_LOAD to aid canonical", " checks", " - KVM: x86: model canonical checks more precisely", " - x86/hyperv: Fix APIC ID and VP index confusion in hv_snp_boot_ap()", " - arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage", " - Drivers: hv: Make the sysfs node size for the ring buffer dynamic", " - Upstream stable to v6.6.101, v6.12.41", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38351", " - KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38675", " - xfrm: state: initialize state_ptrs earlier in xfrm_state_find", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38322", " - perf/x86/intel: Fix crash in icl_update_topdown_event()", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-37777", " - ksmbd: fix use-after-free in __smb2_lease_break_noti()", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-37925", " - jfs: reject on-disk inodes of an unsupported type", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38663", " - nilfs2: reject invalid file types when reading inodes", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38664", " - ice: Fix a null pointer dereference in ice_copy_and_init_pkg()", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38670", " - arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38671", " - i2c: qup: jump out of the loop in case of timeout", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-39726", " - s390/ism: fix concurrency management in ism_cmd()", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38665", " - can: netlink: can_changelink(): fix NULL pointer deref of struct", " can_priv::do_set_mode", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38668", " - regulator: core: fix NULL dereference on unbind due to stale coupling", " data", "", " * Noble update: upstream stable patchset 2025-12-16 (LP: #2136361) //", " CVE-2025-38335", " - Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221)", " - phy: tegra: xusb: Decouple CYA_TRK_CODE_UPDATE_ON_IDLE from trk_hw_mode", " - phy: tegra: xusb: Disable periodic tracking on Tegra234", " - USB: serial: option: add Telit Cinterion FE910C04 (ECM) composition", " - USB: serial: option: add Foxconn T99W640", " - USB: serial: ftdi_sio: add support for NDI EMGUIDE GEMINI", " - usb: musb: fix gadget state on disconnect", " - i2c: stm32: fix the device used for the DMA map", " - thunderbolt: Fix wake on connect at runtime", " - thunderbolt: Fix bit masking in tb_dp_port_set_hops()", " - nvmem: imx-ocotp: fix MAC address byte length", " - Input: xpad - set correct controller type for Acer NGR200", " - pch_uart: Fix dma_sync_sg_for_device() nents value", " - spi: Add check for 8-bit transfer with 8 IO mode support", " - HID: core: ensure __hid_request reserves the report ID as the first byte", " - tracing/probes: Avoid using params uninitialized in parse_btf_arg()", " - drm/amdgpu/gfx8: reset compute ring wptr on the GPU on resume", " - ALSA: hda/realtek: Add quirk for ASUS ROG Strix G712LWS", " - io_uring/poll: fix POLLERR handling", " - phonet/pep: Move call to pn_skb_get_dst_sockaddr() earlier in", " pep_sock_accept()", " - net/mlx5: Update the list of the PCI supported devices", " - arm64: dts: imx8mp-venice-gw74xx: fix TPM SPI frequency", " - arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on", " - arm64: dts: rockchip: use cs-gpios for spi1 on ringneck", " - af_packet: fix the SO_SNDTIMEO constraint not effective on tpacked_snd()", " - af_packet: fix soft lockup issue caused by tpacket_snd()", " - isofs: Verify inode mode when loading from disk", " - memstick: core: Zero initialize id_reg in h_memstick_read_dev_id()", " - mmc: bcm2835: Fix dma_unmap_sg() nents value", " - mmc: sdhci-pci: Quirk for broken command queuing on Intel GLK-based", " Positivo models", " - mmc: sdhci_am654: Workaround for Errata i2312", " - pmdomain: governor: Consider CPU latency tolerance from", " pm_domain_cpu_gov", " - soc: aspeed: lpc-snoop: Cleanup resources in stack-order", " - iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[]", " - iio: adc: max1363: Reorder mode_list[] entries", " - iio: adc: stm32-adc: Fix race in installing chained IRQ handler", " - comedi: Fix some signed shift left operations", " - soundwire: amd: fix for handling slave alerts after link is down", " - soundwire: amd: fix for clearing command status register", " - cachefiles: Fix the incorrect return value in __cachefiles_write()", " - net: emaclite: Fix missing pointer increment in aligned_read()", " - block: fix kobject leak in blk_unregister_queue", " - nvme: fix inconsistent RCU list manipulation in", " nvme_ns_add_to_ctrl_list()", " - nvme: fix misaccounting of nvme-mpath inflight I/O", " - wifi: cfg80211: remove scan request n_channels counted_by", " - selftests: net: increase inter-packet timeout in udpgro.sh", " - Bluetooth: hci_sync: fix connectable extended advertising when using", " static random address", " - Bluetooth: SMP: If an unallowed command is received consider it a", " failure", " - Bluetooth: SMP: Fix using HCI_ERROR_REMOTE_USER_TERM on timeout", " - Bluetooth: btusb: QCA: Fix downloading wrong NVM for WCN6855 GF variant", " without board ID", " - net/mlx5: Correctly set gso_size when LRO is used", " - Bluetooth: L2CAP: Fix attempting to adjust outgoing MTU", " - hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent", " IPv6 addrconf", " - net: bridge: Do not offload IGMP/MLD messages", " - rxrpc: Fix transmission of an abort in response to an abort", " - Revert \"cgroup_freezer: cgroup_freezing: Check if not frozen\"", " - sched: Change nr_uninterruptible type to unsigned long", " - ipv6: make addrconf_wq single threaded", " - usb: hub: fix detection of high tier USB3 devices behind suspended hubs", " - usb: hub: Fix flushing and scheduling of delayed work that tunes runtime", " pm", " - usb: hub: Fix flushing of delayed work used for post resume purposes", " - usb: hub: Don't try to recover devices lost during warm reset.", " - usb: dwc3: qcom: Don't leave BCR asserted", " - i2c: omap: Add support for setting mux", " - [Config] make mux support built-in on arm", " - i2c: omap: Fix an error handling path in omap_i2c_probe()", " - i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()", " - Revert \"selftests/bpf: adjust dummy_st_ops_success to detect additional", " error\"", " - Revert \"selftests/bpf: dummy_st_ops should reject 0 for non-nullable", " params\"", " - i2c: omap: fix deprecated of_property_read_bool() use", " - nvmem: layouts: u-boot-env: remove crc32 endianness conversion", " - i2c: stm32f7: unmap DMA mapped buffer", " - drm/amdgpu: Increase reset counter only on success", " - ALSA: hda/realtek - Fix mute LED for HP Victus 16-r0xxx", " - mptcp: reset fallback status gracefully at disconnect() time", " - arm64: dts: imx8mp-venice-gw72xx: fix TPM SPI frequency", " - arm64: dts: imx8mp-venice-gw73xx: fix TPM SPI frequency", " - arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi CM5", " - arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi 4B", " - nvme: fix endianness of command word prints in nvme_log_err_passthru()", " - nvmet-tcp: fix callback lock for TLS handshake", " - can: tcan4x5x: add option for selecting nWKRQ voltage", " - can: tcan4x5x: fix reset gpio usage during probe", " - ice: check correct pointer in fwlog debugfs", " - riscv: Enable interrupt during exception handling", " - riscv: traps_misaligned: properly sign extend value in misaligned load", " handler", " - Bluetooth: hci_core: add missing braces when using macro parameters", " - drm/mediatek: Add wait_event_timeout when disabling plane", " - drm/mediatek: only announce AFBC if really supported", " - net: libwx: fix multicast packets received count", " - sched,freezer: Remove unnecessary warning in __thaw_task", " - drm/xe/mocs: Initialize MOCS index early", " - drm/xe: Move page fault init after topology init", " - smb: client: let smbd_post_send_iter() respect the peers max_send_size", " and transmit all data", " - Upstream stable to v6.6.100, v6.12.40", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-22115", " - btrfs: fix block group refcount race in", " btrfs_create_pending_block_groups()", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38549", " - efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38551", " - virtio-net: fix recursived rtnl_lock() during probe()", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38531", " - iio: common: st_sensors: Fix use of uninitialize device structs", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38552", " - mptcp: plug races between subflow fail and subflow creation", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38491", " - mptcp: make fallback action and fallback decision atomic", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38469", " - KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll", " hypercalls", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38499", " - clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the", " right userns", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38524", " - rxrpc: Fix recv-recv race of completed call", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38468", " - net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38470", " - net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during", " runtime", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38471", " - tls: always refresh the queue when reading sock", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38472", " - netfilter: nf_conntrack: fix crash due to removal of uninitialised entry", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38550", " - ipv6: mcast: Delay put pmc->idev in mld_del_delrec()", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38473", " - Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38474", " - usb: net: sierra: check for no status endpoint", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38526", " - ice: add NULL check in eswitch lag check", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38548", " - hwmon: (corsair-cpro) Validate the size of the received input buffer", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38537", " - net: phy: Don't register LEDs for genphy", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38527", " - smb: client: fix use-after-free in cifs_oplock_break", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38476", " - rpl: Fix use-after-free in rpl_do_srh_inline().", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38528", " - bpf: Reject %p% format string in bprintf-like helpers", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38478", " - comedi: Fix initialization of data for instructions that write to", " subdevice", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38480", " - comedi: Fix use of uninitialized data in insn_rw_emulate_bits()", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38481", " - comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38482", " - comedi: das6402: Fix bit shift out of bounds", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38483", " - comedi: das16m1: Fix bit shift out of bounds", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38529", " - comedi: aio_iiro_16: Fix bit shift out of bounds", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38530", " - comedi: pcl812: Fix bit shift out of bounds", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38485", " - iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38487", " - soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2024-50047 fix. // CVE-2025-38488", " - smb: client: fix use-after-free in crypt_message when using async crypto", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38489", " - s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38532", " - net: libwx: properly reset Rx ring descriptor", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38533", " - net: libwx: fix the using of Rx buffer DMA", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38490", " - net: libwx: remove duplicate page_pool_put_full_page()", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38538", " - dmaengine: nbpfaxi: Fix memory corruption in probe()", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38493", " - tracing/osnoise: Fix crash in timerlat_dump_stack()", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38539", " - tracing: Add down_write(trace_event_sem) when adding trace event", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38494", " - HID: core: do not bypass hid_hw_raw_request", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38495", " - HID: core: ensure the allocated report buffer can contain the reserved", " report ID", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38496", " - dm-bufio: fix sched in atomic context", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38497", " - usb: gadget: configfs: Fix OOB read on empty string write", "", " * Noble update: upstream stable patchset 2025-12-15 (LP: #2136221) //", " CVE-2025-38535", " - phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382)", " - configfs: Do not override creating attribute file failure in", " populate_attrs()", " - crypto: marvell/cesa - Do not chain submitted requests", " - gfs2: move msleep to sleepable context", " - ASoC: qcom: sdm845: Add error handling in sdm845_slim_snd_hw_params()", " - ASoC: meson: meson-card-utils: use of_property_present() for DT parsing", " - io_uring: account drain memory to cgroup", " - io_uring/kbuf: account ring io_buffer_list memory", " - powerpc/pseries/msi: Avoid reading PCI device registers in reduced power", " states", " - regulator: max20086: Fix MAX200086 chip id", " - regulator: max20086: Change enable gpio to optional", " - net/mlx5_core: Add error handling", " inmlx5_query_nic_vport_qkey_viol_cntr()", " - net/mlx5: Add error handling in mlx5_query_nic_vport_node_guid()", " - wifi: ath11k: fix rx completion meta data corruption", " - wifi: ath11k: fix ring-buffer corruption", " - SUNRPC: Prevent hang on NFS mount with xprtsec=[m]tls", " - wifi: ath12k: fix ring-buffer corruption", " - wifi: rtw88: usb: Reduce control message timeout to 500 ms", " - wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723", " - media: ov8856: suppress probe deferral errors", " - media: ov5675: suppress probe deferral errors", " - media: nxp: imx8-isi: better handle the m2m usage_count", " - media: i2c: ds90ub913: Fix returned fmt from .set_fmt()", " - media: ccs-pll: Start VT pre-PLL multiplier search from correct value", " - media: ccs-pll: Start OP pre-PLL multiplier search from correct value", " - media: ccs-pll: Correct the upper limit of maximum op_pre_pll_clk_div", " - media: ccs-pll: Check for too high VT PLL multiplier in dual PLL case", " - media: davinci: vpif: Fix memory leak in probe error path", " - media: gspca: Add error handling for stv06xx_read_sensor()", " - media: mediatek: vcodec: Correct vsi_core framebuffer size", " - media: omap3isp: use sgtable-based scatterlist wrappers", " - media: v4l2-dev: fix error handling in __video_register_device()", " - media: venus: Fix probe error handling", " - media: videobuf2: use sgtable-based scatterlist wrappers", " - media: imx-jpeg: Drop the first error frames", " - media: imx-jpeg: Move mxc_jpeg_free_slot_data() ahead", " - media: imx-jpeg: Reset slot data pointers when freed", " - media: uvcvideo: Return the number of processed controls", " - media: uvcvideo: Send control events for partial succeeds", " - media: uvcvideo: Fix deferred probing error", " - arm64/mm: Close theoretical race where stale TLB entry remains valid", " - ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap()", " - ARM: omap: pmic-cpcap: do not mess around without CPCAP or OMAP4", " - bus: mhi: host: Fix conflict between power_up and SYSERR", " - can: tcan4x5x: fix power regulator retrieval during probe", " - ceph: set superblock s_magic for IMA fsmagic matching", " - cgroup,freezer: fix incomplete freezing when attaching tasks", " - bus: fsl-mc: do not add a device-link for the UAPI used DPMCP device", " - bus: fsl-mc: fix GET/SET_TAILDROP command ids", " - ext4: fix calculation of credits for extent tree modification", " - ext4: factor out ext4_get_maxbytes()", " - ext4: ensure i_size is smaller than maxbytes", " - Input: gpio-keys - fix possible concurrent access in", " gpio_keys_irq_timer()", " - net: ftgmac100: select FIXED_PHY", " - EDAC/altera: Use correct write width with the INTTEST register", " - parisc/unaligned: Fix hex output to show 8 hex chars", " - parisc: fix building with gcc-15", " - clk: meson-g12a: add missing fclk_div2 to spicc", " - watchdog: fix watchdog may detect false positive of softlockup", " - mm: fix ratelimit_pages update error in dirty_ratio_handler()", " - mtd: rawnand: sunxi: Add randomizer configuration in", " sunxi_nfc_hw_ecc_write_chunk", " - mtd: nand: sunxi: Add randomizer configuration before randomizer enable", " - KVM: SVM: Clear current_vmcb during vCPU free for all *possible* CPUs", " - KVM: VMX: Flush shadow VMCS on emergency reboot", " - dm-mirror: fix a tiny race condition", " - dm-verity: fix a memory leak if some arguments are specified multiple", " times", " - mtd: rawnand: qcom: Fix read len for onfi param page", " - phy: fsl-imx8mq-usb: fix phy_tx_vboost_level_from_property()", " - KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMY", " - staging: iio: ad5933: Correct settling cycles encoding per datasheet", " - mips: Add -std= flag specified in KBUILD_CFLAGS to vdso CFLAGS", " - regulator: max14577: Add error check for max14577_read_reg()", " - cifs: reset connections for all channels when reconnect requested", " - cifs: update dstaddr whenever channel iface is updated", " - cifs: dns resolution is needed only for primary channel", " - Drivers: hv: Allocate interrupt and monitor pages aligned to system page", " boundary", " - uio_hv_generic: Use correct size for interrupt and monitor pages", " - PCI: cadence-ep: Correct PBA offset in .set_msix() callback", " - PCI: Add ACS quirk for Loongson PCIe", " - PCI: Fix lock symmetry in pci_slot_unlock()", " - PCI: dw-rockchip: Fix PHY function call sequence in", " rockchip_pcie_phy_deinit()", " - iio: accel: fxls8962af: Fix temperature scan element sign", " - iio: imu: inv_icm42600: Fix temperature calculation", " - iio: adc: ad7606_spi: fix reg write value mask", " - ASoC: amd: yc: Add quirk for Lenovo Yoga Pro 7 14ASP9", " - clocksource: Fix the CPUs' choice in the watchdog per CPU verification", " - power: supply: collie: Fix wakeup source leaks on device unbind", " - mmc: Add quirk to disable DDR50 tuning", " - ACPICA: Avoid sequence overread in call to strncmp()", " - ASoC: tas2770: Power cycle amp on ISENSE/VSENSE change", " - ACPI: bus: Bail out if acpi_kobj registration fails", " - ACPI: Add missing prototype for non CONFIG_SUSPEND/CONFIG_X86 case", " - power: supply: bq27xxx: Retrieve again when busy", " - ACPICA: utilities: Fix overflow check in vsnprintf()", " - ASoC: tegra210_ahub: Add check to of_device_get_match_data()", " - gpiolib: of: Add polarity quirk for s5m8767", " - PM: runtime: fix denying of auto suspend in pm_suspend_timer_fn()", " - net: macb: Check return value of dma_set_mask_and_coherent()", " - tipc: use kfree_sensitive() for aead cleanup", " - f2fs: use vmalloc instead of kvmalloc in .init_{,de}compress_ctx", " - i2c: designware: Invoke runtime suspend on quick slave re-registration", " - emulex/benet: correct command version selection in be_cmd_get_stats()", " - wifi: mt76: mt76x2: Add support for LiteOn WN4516R,WN4519R", " - wifi: mt76: mt7921: add 160 MHz AP for mt7922 device", " - sctp: Do not wake readers in __sctp_write_space()", " - cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs", " - i2c: npcm: Add clock toggle recovery", " - net: dlink: add synchronization for stats update", " - wifi: ath12k: fix macro definition HAL_RX_MSDU_PKT_LENGTH_GET", " - wifi: ath12k: fix a possible dead lock caused by ab->base_lock", " - wifi: ath11k: Fix QMI memory reuse logic", " - wifi: rtw89: leave idle mode when setting WEP encryption for AP mode", " - tcp: always seek for minimal rtt in tcp_rcv_rtt_update()", " - tcp: fix initial tp->rcvq_space.space value for passive TS enabled flows", " - ipv4/route: Use this_cpu_inc() for stats on PREEMPT_RT", " - net: atlantic: generate software timestamp just before the doorbell", " - pinctrl: armada-37xx: propagate error from armada_37xx_pmx_set_by_name()", " - pinctrl: armada-37xx: propagate error from", " armada_37xx_gpio_get_direction()", " - pinctrl: armada-37xx: propagate error from", " armada_37xx_pmx_gpio_set_direction()", " - pinctrl: armada-37xx: propagate error from armada_37xx_gpio_get()", " - net: mlx4: add SOF_TIMESTAMPING_TX_SOFTWARE flag when getting ts info", " - net: vertexcom: mse102x: Return code for mse102x_rx_pkt_spi", " - wireless: purelifi: plfxlc: fix memory leak in plfxlc_usb_wreq_asyn()", " - wifi: mac80211: do not offer a mesh path if forwarding is disabled", " - clk: rockchip: rk3036: mark ddrphy as critical", " - libbpf: Add identical pointer detection to btf_dedup_is_equiv()", " - scsi: lpfc: Fix lpfc_check_sli_ndlp() handling for GEN_REQUEST64", " commands", " - iommu/amd: Ensure GA log notifier callbacks finish running before module", " unload", " - wifi: iwlwifi: pcie: make sure to lock rxq->read", " - wifi: mac80211_hwsim: Prevent tsf from setting if beacon is disabled", " - wifi: mac80211: VLAN traffic in multicast path", " - wifi: iwlwifi: Add missing MODULE_FIRMWARE for Qu-c0-jf-b0", " - net: bridge: mcast: update multicast contex when vlan state is changed", " - net: bridge: mcast: re-implement br_multicast_{enable, disable}_port", " functions", " - vxlan: Do not treat dst cache initialization errors as fatal", " - net: ethernet: ti: am65-cpsw: handle -EPROBE_DEFER", " - pinctrl: mcp23s08: Reset all pins to input at probe", " - wifi: ath12k: fix failed to set mhi state error during reboot with", " hardware grouping", " - sock: Correct error checking condition for (assign|release)_proto_idx()", " - ice: fix check for existing switch rule", " - usbnet: asix AX88772: leave the carrier control to phylink", " - f2fs: fix to set atomic write status more clear", " - bpf, sockmap: Fix data lost during EAGAIN retries", " - octeontx2-pf: Add error log forcn10k_map_unmap_rq_policer()", " - wifi: ath11k: determine PM policy based on machine model", " - wifi: ath12k: fix link valid field initialization in the monitor Rx", " - wifi: ath12k: fix incorrect CE addresses", " - wifi: ath12k: Pass correct values of center freq1 and center freq2 for", " 160 MHz", " - watchdog: da9052_wdt: respect TWDMIN", " - bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value", " - ARM: OMAP2+: Fix l4ls clk domain handling in STANDBY", " - tee: Prevent size calculation wraparound on 32-bit kernels", " - Revert \"bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices", " first\"", " - fs/xattr.c: fix simple_xattr_list()", " - platform/x86/amd: pmc: Clear metrics table at start of cycle", " - platform/x86: dell_rbu: Stop overwriting data buffer", " - powerpc/vdso: Fix build of VDSO32 with pcrel", " - powerpc/eeh: Fix missing PE bridge reconfiguration during VFIO EEH", " recovery", " - io_uring: fix task leak issue in io_wq_create()", " - platform/loongarch: laptop: Get brightness setting from EC on probe", " - platform/loongarch: laptop: Unregister generic_sub_drivers on exit", " - LoongArch: Avoid using $r0/$r1 as \"mask\" for csrxchg", " - cifs: deal with the channel loading lag while picking channels", " - cifs: serialize other channels when query server interfaces is pending", " - cifs: do not disable interface polling on failure", " - smb: improve directory cache reuse for readdir operations", " - scsi: storvsc: Increase the timeouts to storvsc_timeout", " - scsi: s390: zfcp: Ensure synchronous unit_add", " - udmabuf: use sgtable-based scatterlist wrappers", " - selftests/x86: Add a test to detect infinite SIGTRAP handler loop", " - selinux: fix selinux_xfrm_alloc_user() to set correct ctx_len", " - platform/x86/intel-uncore-freq: Fail module load when plat_info is NULL", " - Input: sparcspkr - avoid unannotated fall-through", " - wifi: rtw89: pci: use DBI function for 8852AE/8852BE/8851BE", " - arm64: Restrict pagetable teardown to avoid false warning", " - ALSA: usb-audio: Rename ALSA kcontrol PCM and PCM1 for the KTMicro sound", " card", " - ALSA: hda/intel: Add Thinkpad E15 to PM deny list", " - ALSA: hda/realtek: enable headset mic on Latitude 5420 Rugged", " - iio: accel: fxls8962af: Fix temperature calculation", " - net: Fix checksum update for ILA adj-transport", " - bpf: Fix L4 csum update on IPv6 in CHECKSUM_COMPLETE", " - erofs: remove unused trace event erofs_destroy_inode", " - smb: fix secondary channel creation issue with kerberos by populating", " hostname when adding channels", " - drm/msm/disp: Correct porch timing for SDM845", " - drm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rate", " - ionic: Prevent driver/fw getting out of sync on devcmd(s)", " - drm/nouveau/bl: increase buffer size to avoid truncate warning", " - drm/i915/pmu: Fix build error with GCOV and AutoFDO enabled", " - hwmon: (occ) Rework attribute registration for stack usage", " - hwmon: (occ) fix unaligned accesses", " - pldmfw: Select CRC32 when PLDMFW is selected", " - net: ice: Perform accurate aRFS flow match", " - ptp: fix breakage after ptp_vclock_in_use() rework", " - ptp: allow reading of currently dialed frequency to succeed on free-", " running clocks", " - tcp: fix tcp_packet_delayed() for tcp_is_non_sack_preventing_reopen()", " behavior", " - tcp: fix passive TFO socket having invalid NAPI ID", " - net: microchip: lan743x: Reduce PTP timeout on HW failure", " - EDAC/amd64: Correct number of UMCs for family 19h models 70h-7fh", " - dt-bindings: i2c: nvidia,tegra20-i2c: Specify the required properties", " - net: make for_each_netdev_dump() a little more bug-proof", " - serial: sh-sci: Increment the runtime usage counter for the earlycon", " device", " - ARM: dts: am335x-bone-common: Increase MDIO reset deassert time", " - ARM: dts: am335x-bone-common: Increase MDIO reset deassert delay to 50ms", " - smb: client: fix first command failure during re-negotiation", " - platform/loongarch: laptop: Add backlight power control support", " - s390/pci: Fix __pcilg_mio_inuser() inline assembly", " - perf: Fix cgroup state vs ERROR", " - perf/core: Fix WARN in perf_cgroup_switch()", " - scsi: elx: efct: Fix memory leak in efct_hw_parse_filter()", " - RISC-V: KVM: Fix the size parameter check in SBI SFENCE calls", " - RISC-V: KVM: Don't treat SBI HFENCE calls as NOPs", " - perf evsel: Missed close() when probing hybrid core PMUs", " - crypto: qat - add shutdown handler to qat_c3xxx", " - crypto: qat - add shutdown handler to qat_420xx", " - crypto: qat - add shutdown handler to qat_4xxx", " - crypto: qat - add shutdown handler to qat_c62x", " - crypto: qat - add shutdown handler to qat_dh895xcc", " - wifi: mt76: mt7925: fix host interrupt register initialization", " - wifi: rtw88: usb: Upload the firmware in bigger chunks", " - NFSD: unregister filesystem in case genl_register_family() fails", " - NFSD: Implement FATTR4_CLONE_BLKSIZE attribute", " - media: ov2740: Move pm-runtime cleanup on probe-errors to proper place", " - media: i2c: imx335: Fix frame size enumeration", " - soc: qcom: pmic_glink_altmode: fix spurious DP hotplug events", " - sysfb: Fix screen_info type check for VGA", " - ovl: Fix nested backing file paths", " - Drivers: hv: vmbus: Add utility function for querying ring size", " - uio_hv_generic: Query the ringbuffer size for device", " - uio_hv_generic: Align ring size to system page", " - PCI: dwc: ep: Correct PBA offset in .set_msix() callback", " - PCI: dw-rockchip: Remove PCIE_L0S_ENTRY check from", " rockchip_pcie_link_up()", " - accel/ivpu: Improve buffer object logging", " - accel/ivpu: Fix warning in ivpu_gem_bo_free()", " - tty: vt: make init parameter of consw::con_init() a bool", " - tty: vt: sanitize arguments of consw::con_clear()", " - tty: vt: make consw::con_switch() return a bool", " - dummycon: Trigger redraw when switching consoles with deferred takeover", " - ACPICA: Apply pack(1) to union aml_resource", " - ALSA: hda: cs35l41: Fix swapped l/r audio channels for Acer Helios", " laptops", " - pmdomain: core: Reset genpd->states to avoid freeing invalid data", " - power: supply: max17040: adjust thermal channel scaling", " - Bluetooth: btusb: Add new VID/PID 13d3/3584 for MT7922", " - Bluetooth: btusb: Add new VID/PID 13d3/3630 for MT7925", " - wifi: mt76: mt7925: introduce thermal protection", " - libbpf/btf: Fix string handling to support multi-split BTF", " - clk: qcom: gcc-x1e80100: Set FORCE MEM CORE for UFS clocks", " - iommu/amd: Allow matching ACPI HID devices without matching UIDs", " - tcp: remove zero TCP TS samples for autotuning", " - tcp: add receive queue awareness in tcp_rcv_space_adjust()", " - bpf: Pass the same orig_call value to trampoline functions", " - net: stmmac: generate software timestamp just before the doorbell", " - hid-asus: check ROG Ally MCU version and warn", " - wifi: iwlwifi: mvm: fix beacon CCK flag", " - scsi: smartpqi: Add new PCI IDs", " - Revert \"mac80211: Dynamically set CoDel parameters per station\"", " - bnxt_en: Remove unused field \"ref_count\" in struct bnxt_ulp", " - wifi: ath12k: using msdu end descriptor to check for rx multicast", " packets", " - isofs: fix Y2038 and Y2156 issues in Rock Ridge TF entry", " - ixgbe: Fix unreachable retry logic in combined and byte I2C write", " functions", " - RDMA/hns: initialize db in update_srq_db()", " - platform/x86/amd: pmf: Prevent amd_pmf_tee_deinit() from running twice", " - LoongArch: vDSO: Correctly use asm parameters in syscall wrappers", " - nvme: always punt polled uring_cmd end_io work to task_work", " - mm: close theoretical race where stale TLB entries could linger", " - x86/virt/tdx: Avoid indirect calls to TDX assembly functions", " - wifi: rtw89: phy: add dummy C2H event handler for report of TAS power", " - ALSA: hda/realtek - Add mute LED support for HP Victus 16-s1xxx and HP", " Victus 15-fa1xxx", " - ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X513EA", " - drm/amdgpu: read back register after written for VCN v4.0.5", " - Kunit to check the longest symbol length", " - x86/tools: Drop duplicate unlikely() definition in insn_decoder_test.c", " - ipv6: remove leftover ip6 cookie initializer", " - ipv6: replace ipcm6_init calls with ipcm6_init_sk", " - drm/ssd130x: fix ssd132x_clear_screen() columns", " - workqueue: Initialize wq_isolated_cpumask in workqueue_init_early()", " - mlxbf_gige: return EPROBE_DEFER if PHY IRQ is not available", " - gpio: pca953x: fix wrong error probe return value", " - bpftool: Fix cgroup command to only show cgroup bpf programs", " - Upstream stable to v6.6.95, v6.12.35", " - bpftool: Query only cgroup-related attach types", " - bpftool: Fix regression of \"bpftool cgroup tree\" EINVAL on older kernels", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38507", " - HID: nintendo: avoid bluetooth suspend/resume stalls", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38511", " - drm/xe/pf: Clear all LMTT pages on alloc", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38520", " - drm/amdkfd: Don't call mmput from MMU notifier callback", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38521", " - drm/imagination: Fix kernel crash when hard resetting the GPU", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38506", " - KVM: Allow CPU to reschedule while setting per-page memory attributes", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38104", " - drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to", " avoid Priority Inversion in SRIOV", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38067", " - rseq: Fix segfault on registration when rseq_cs is non-zero", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-37984", " - crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38437", " - ksmbd: fix potential use-after-free in oplock/lease break ack", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38510", " - kasan: remove kasan_find_vm_area() to prevent possible deadlock", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38503", " - btrfs: fix assertion when building free space tree", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38439", " - bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38542", " - net: appletalk: Fix device refcount leak in atrtr_create()", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38441", " - netfilter: flowtable: account for Ethernet header in", " nf_flow_pppoe_proto()", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38443", " - nbd: fix uaf in nbd_genl_connect() error path", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38444", " - raid10: cleanup memleak at raid10_make_request", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38445", " - md/raid1: Fix stack memory use after return in raid1_reshape", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38543", " - drm/tegra: nvdec: Fix dma_alloc_coherent error check", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38513", " - wifi: zd1211rw: Fix potential NULL pointer dereference in", " zd_mac_tx_to_dev()", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38448", " - usb: gadget: u_serial: Fix race condition in TTY wakeup", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38515", " - drm/sched: Increment job count before swapping tail spsc queue", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38449", " - drm/gem: Acquire references on GEM handles for framebuffers", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38512", " - wifi: prevent A-MSDU attacks in mesh networks", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38516", " - pinctrl: qcom: msm: mark certain pins as invalid for interrupts", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38455", " - KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-", " flight", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38456", " - ipmi:msghandler: Fix potential memory corruption in ipmi_create_user()", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38514", " - rxrpc: Fix oops due to non-existence of prealloc backlog struct", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38544", " - rxrpc: Fix bug due to prealloc collision", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38457", " - net/sched: Abort __tc_modify_qdisc if parent class does not exist", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38458", " - atm: clip: Fix NULL pointer dereference in vcc_sendmsg()", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38459", " - atm: clip: Fix infinite recursive call of clip_push().", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38546", " - atm: clip: Fix memory leak of struct clip_vcc.", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38460", " - atm: clip: Fix potential null-ptr-deref in to_atmarpd().", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38461", " - vsock: Fix transport_* TOCTOU", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38462", " - vsock: Fix transport_{g2h,h2g} TOCTOU", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38463", " - tcp: Correct signedness in skb remaining space calculation", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38464", " - tipc: Fix use-after-free in tipc_conn_close().", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38465", " - netlink: Fix wraparounds of sk->sk_rmem_alloc.", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38466", " - perf: Revert to requiring CAP_SYS_ADMIN for uprobes", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38467", " - drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling", "", " * Noble update: upstream stable patchset 2025-12-12 (LP: #2135261) //", " CVE-2025-38349", " - eventpoll: don't decrement ep refcount while still holding the ep mutex", "", " * [UBUNTU 24.04] KVM: s390: improve interrupt cpu for wakeup (LP: #2132317)", " - KVM: s390: improve interrupt cpu for wakeup", "", " * veth.sh from ubuntu_kselftests_net failed on J-5.15 / N-6.8 (with xdp", " attached - gro flag) (LP: #2065369)", " - selftests: net: veth: test the ability to independently manipulate GRO", " and XDP", "", " * ftrace:test.d--event--subsystem-enable.tc fails on some instances", " (LP: #2071861)", " - selftests/tracing: Fix false failure of subsystem event test", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640)", " - rtc: pcf2127: add missing semicolon after statement", " - rtc: pcf2127: fix SPI command byte for PCF2131", " - rtc: cmos: use spin_lock_irqsave in cmos_interrupt", " - mmc: sdhci: Add a helper function for dump register in dynamic debug", " mode", " - mmc: core: sd: Apply BROKEN_SD_DISCARD quirk earlier", " - Bluetooth: hci_sync: revert some mesh modifications", " - Bluetooth: MGMT: set_mesh: update LE scan interval and window", " - Bluetooth: MGMT: mesh_send: check instances prior disabling advertising", " - mtk-sd: Fix a pagefault in dma_unmap_sg() for not prepared data", " - mtk-sd: reset host->mrq on prepare_data() error", " - arm64: dts: apple: t8103: Fix PCIe BCM4377 nodename", " - platform/mellanox: mlxbf-tmfifo: fix vring_desc.len assignment", " - scsi: qla2xxx: Fix DMA mapping test in qla24xx_get_port_database()", " - scsi: qla4xxx: Fix missing DMA mapping error in qla4xxx_alloc_pdu()", " - scsi: ufs: core: Fix spelling of a sysfs attribute name", " - RDMA/mlx5: Fix HW counters query for non-representor devices", " - RDMA/mlx5: Fix CC counters query for MPV", " - RDMA/mlx5: Fix vport loopback for MPV device", " - platform/mellanox: nvsw-sn2201: Fix bus number in adapter error message", " - Bluetooth: Prevent unintended pause by checking if advertising is active", " - btrfs: fix missing error handling when searching for inode refs during", " log replay", " - btrfs: rename err to ret in btrfs_rmdir()", " - btrfs: propagate last_unlink_trans earlier when doing a rmdir", " - btrfs: use btrfs_record_snapshot_destroy() during rmdir", " - ethernet: atl1: Add missing DMA mapping error checks and count errors", " - dpaa2-eth: fix xdp_rxq_info leak", " - drm/exynos: fimd: Guard display clock control with runtime PM calls", " - spi: spi-fsl-dspi: Clear completion counter before initiating transfer", " - drm/i915/selftests: Change mock_request() to return error pointers", " - platform/x86: make fw_attr_class constant", " - platform/x86: firmware_attributes_class: Move include", " linux/device/class.h", " - platform/x86: firmware_attributes_class: Simplify API", " - platform/x86: think-lmi: Directly use firmware_attributes_class", " - platform/x86: think-lmi: Fix class device unregistration", " - platform/x86: dell-sysman: Directly use firmware_attributes_class", " - platform/x86: dell-wmi-sysman: Fix class device unregistration", " - platform/mellanox: mlxreg-lc: Fix logic error in power state check", " - smb: client: fix warning when reconnecting channel", " - drm/i915/gsc: mei interrupt top half should be in irq disabled context", " - igc: disable L1.2 PCI-E link substate to avoid performance issue", " - lib: test_objagg: Set error message in check_expect_hints_stats()", " - amd-xgbe: align CL37 AN sequence as per databook", " - enic: fix incorrect MTU comparison in enic_change_mtu()", " - nui: Fix dma_mapping_error() check", " - amd-xgbe: do not double read link status", " - smb: client: fix race condition in negotiate timeout by using more", " precise timing", " - wifi: mac80211: chan: chandef is non-NULL for reserved", " - f2fs: prevent writing without fallocate() for pinned files", " - f2fs: convert f2fs_vm_page_mkwrite() to use folio", " - f2fs: fix to zero post-eof page", " - drm/simpledrm: Do not upcast in release helpers", " - ALSA: sb: Don't allow changing the DMA mode during operations", " - ALSA: sb: Force to disable DMAs once when DMA mode is changed", " - ata: libata-acpi: Do not assume 40 wire cable if no devices are enabled", " - ata: pata_cs5536: fix build on 32-bit UML", " - ASoC: amd: yc: Add quirk for MSI Bravo 17 D7VF internal mic", " - platform/x86/amd/pmc: Add PCSpecialist Lafite Pro V 14M to 8042 quirks", " list", " - powerpc: Fix struct termio related ioctl macros", " - ASoC: amd: yc: update quirk data for HP Victus", " - regulator: fan53555: add enable_time support and soft-start times", " - aoe: defer rexmit timer downdev work to workqueue", " - wifi: mac80211: drop invalid source address OCB frames", " - rcu: Return early if callback is not specified", " - platform/x86: hp-bioscfg: Directly use firmware_attributes_class", " - platform/x86: hp-bioscfg: Fix class device unregistration", " - module: Provide EXPORT_SYMBOL_GPL_FOR_MODULES() helper", " - NFSv4/flexfiles: Fix handling of NFS level errors in I/O", " - usb: xhci: quirk for data loss in ISOC transfers", " - xhci: dbctty: disable ECHO flag by default", " - xhci: dbc: Flush queued requests before stopping dbc", " - xhci: Disable stream for xHC controller with XHCI_BROKEN_STREAMS", " - Input: xpad - support Acer NGR 200 Controller", " - Input: iqs7222 - explicitly define number of external channels", " - usb: cdnsp: do not disable slot for disabled slot", " - dma-buf: fix timeout handling in dma_resv_wait_timeout v2", " - i2c/designware: Fix an initialization issue", " - Logitech C-270 even more broken", " - iommu/rockchip: prevent iommus dead loop when two masters share one", " IOMMU", " - powercap: intel_rapl: Do not change CLAMPING bit if ENABLE bit cannot be", " changed", " - platform/x86: think-lmi: Create ksets consecutively", " - platform/x86: think-lmi: Fix kobject cleanup", " - platform/x86: think-lmi: Fix sysfs group cleanup", " - usb: typec: displayport: Fix potential deadlock", " - powerpc/kernel: Fix ppc_save_regs inclusion in build", " - [Config] enable Transient Scheduler Attacks mitigation", " - x86/CPU/AMD: Properly check the TSA microcode", " - x86/bugs: Fix use of possibly uninit value in amd_check_tsa_microcode()", " - net: txgbe: request MISC IRQ in ndo_open", " - Bluetooth: HCI: Set extended advertising data synchronously", " - iommufd/selftest: Fix iommufd_dirty_tracking with large hugepage sizes", " - firmware: arm_ffa: Move memory allocation outside the mutex locking", " - platform/mellanox: mlxbf-pmc: Fix duplicate event ID for CACHE_DATA1", " - btrfs: return a btrfs_inode from btrfs_iget_logging()", " - btrfs: return a btrfs_inode from read_one_inode()", " - btrfs: fix invalid inode pointer dereferences during log replay", " - btrfs: fix inode lookup error handling during log replay", " - nvme: Fix incorrect cdw15 value in passthru error logging", " - drm/bridge: aux-hpd-bridge: fix assignment of the of_node", " - netfs: Fix i_size updating", " - arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma", " - crypto: iaa - Remove dst_null support", " - crypto: iaa - Do not clobber req->base.data", " - spinlock: extend guard with spinlock_bh variants", " - crypto: zynqmp-sha - Add locking", " - kunit: qemu_configs: sparc: use Zilog console", " - kunit: qemu_configs: sparc: Explicitly enable CONFIG_SPARC32=y", " - kunit: qemu_configs: Disable faulting tests on 32-bit SPARC", " - gfs2: Initialize gl_no_formal_ino earlier", " - gfs2: Rename GIF_{DEFERRED -> DEFER}_DELETE", " - gfs2: Rename dinode_demise to evict_behavior", " - gfs2: Prevent inode creation race", " - gfs2: Rename GLF_FREEING to GLF_UNLOCKED", " - gfs2: Decode missing glock flags in tracepoints", " - gfs2: Add GLF_PENDING_REPLY flag", " - gfs2: Replace GIF_DEFER_DELETE with GLF_DEFER_DELETE", " - gfs2: Move gfs2_dinode_dealloc", " - gfs2: Move GIF_ALLOC_FAILED check out of gfs2_ea_dealloc", " - gfs2: deallocate inodes in gfs2_create_inode", " - btrfs: fix wrong start offset for delalloc space release during mmap", " write", " - ASoC: tas2764: Extend driver to SN012776", " - ASoC: tas2764: Reinit cache on part reset", " - ACPI: thermal: Fix stale comment regarding trip points", " - ACPI: thermal: Execute _SCP before reading trip points", " - bonding: Mark active offloaded xfrm_states", " - wifi: ath12k: Handle error cases during extended skb allocation", " - wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers", " - RDMA/rxe: Fix \"trying to register non-static key in rxe_qp_do_cleanup\"", " bug", " - iommu: ipmmu-vmsa: avoid Wformat-security warning", " - f2fs: decrease spare area for pinned files for zoned devices", " - f2fs: zone: introduce first_zoned_segno in f2fs_sb_info", " - f2fs: introduce SEGS_TO_BLKS/BLKS_TO_SEGS for cleanup", " - f2fs: zone: fix to calculate first_zoned_segno correctly", " - scsi: lpfc: Remove NLP_RELEASE_RPI flag from nodelist structure", " - scsi: lpfc: Change lpfc_nodelist nlp_flag member into a bitmask", " - hisi_acc_vfio_pci: bugfix cache write-back issue", " - hisi_acc_vfio_pci: bugfix the problem of uninstalling driver", " - bpf: use common instruction history across all states", " - arm64: dts: qcom: sm8650: change labels to lower-case", " - arm64: dts: qcom: sm8650: Fix domain-idle-state for CPU2", " - arm64: dts: qcom: sm8650: add the missing l2 cache node", " - remoteproc: k3: Call of_node_put(rmem_np) only once in three functions", " - remoteproc: k3-r5: Add devm action to release reserved memory", " - remoteproc: k3-r5: Use devm_kcalloc() helper", " - remoteproc: k3-r5: Use devm_ioremap_wc() helper", " - remoteproc: k3-r5: Use devm_rproc_alloc() helper", " - remoteproc: k3-r5: Use devm_rproc_add() helper", " - remoteproc: k3-r5: Refactor sequential core power up/down operations", " - mfd: exynos-lpass: Fix another error handling path in", " exynos_lpass_probe()", " - selinux: change security_compute_sid to return the ssid or tsid on match", " - drm/amdgpu: VCN v5_0_1 to prevent FW checking RB during DPG pause", " - drm/xe/bmg: Add BMG platform definition", " - drm/i915/bmg: Define IS_BATTLEMAGE macro", " - drm/i915/dp_mst: Work around Thunderbolt sink disconnect after", " SINK_COUNT_ESI read", " - arm64: dts: qcom: x1e80100-crd: mark l12b and l15b always-on", " - scsi: lpfc: Restore clearing of NLP_UNREG_INP in ndlp->nlp_flag", " - RDMA/mlx5: Fix cache entry update on dereg error", " - drm/xe: Allow dropping kunit dependency as built-in", " - usb: xhci: Skip xhci_reset in xhci_resume if xhci is being removed", " - Revert \"usb: xhci: Implement xhci_handshake_check_state() helper\"", " - usb: cdnsp: Fix issue with CV Bad Descriptor test", " - usb: dwc3: Abort suspend on soft disconnect failure", " - Upstream stable to v6.6.97, v6.12.37", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38407", " - riscv: cpu_ops_sbi: Use static array for boot_data", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38374", " - optee: ffa: fix sleep in atomic context", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38373", " - IB/mlx5: Fix potential deadlock in MR deregistration", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38408", " - genirq/irq_sim: Initialize work context pointers properly", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38279", " - bpf: Do not include stack ptr register in precision backtracking", " bookkeeping", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38289", " - scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbk", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38392", " - idpf: convert control queue mutex to a spinlock", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38402", " - idpf: return 0 size for RSS key if not supported", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38405", " - nvmet: fix memory leak of bio integrity", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38388", " - firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic", " context", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38390", " - firmware: arm_ffa: Fix memory leak by freeing notifier callback node", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2024-36350 // CVE-2024-36357", " - x86/bugs: Rename MDS machinery to something more generic", " - x86/bugs: Add a Transient Scheduler Attacks mitigation", " - KVM: SVM: Advertise TSA CPUID bits to guests", " - x86/microcode/AMD: Add TSA microcode SHAs", " - x86/process: Move the buffer clearing before MONITOR", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38376", " - usb: chipidea: udc: disconnect/reconnect from host when do", " suspend/resume", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38396", " - fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38371", " - drm/v3d: Disable interrupts before resetting the GPU", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38384", " - mtd: spinand: fix memory leak of ECC engine conf", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38386", " - ACPICA: Refuse to evaluate a method if arguments are missing", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38406", " - wifi: ath6kl: remove WARN on bad firmware input", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38399", " - scsi: target: Fix NULL pointer dereference in", " core_scsi3_decode_spec_i_port()", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38409", " - drm/msm: Fix another leak in the submit error path", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38410", " - drm/msm: Fix a fence leak in submit error path", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38377", " - rose: fix dangling neighbour pointers in rose_rt_device_down()", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38389", " - drm/i915/gt: Fix timeline left held on VMA alloc error", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38385", " - net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38412", " - platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs", " callbacks", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38382", " - btrfs: fix iteration of extrefs during log replay", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38393", " - NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38400", " - nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38387", " - RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insert", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38401", " - mtk-sd: Prevent memory corruption from DMA map failure", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38391", " - usb: typec: altmodes/displayport: do not index invalid pin_assignments", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38395", " - regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38403", " - vsock/vmci: Clear the vmci transport packet properly when initializing", " it", "", " * Noble update: upstream stable patchset 2025-12-11 (LP: #2134640) //", " CVE-2025-38375", " - virtio-net: ensure the received length does not exceed allocated size", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499)", " - cifs: Correctly set SMB1 SessionKey field in Session Setup Request", " - cifs: Fix cifs_query_path_info() for Windows NT servers", " - cifs: Fix encoding of SMB1 Session Setup NTLMSSP Request in non-UNICODE", " mode", " - NFSv4: Always set NLINK even if the server doesn't support it", " - NFSv4.2: fix listxattr to return selinux security label", " - mailbox: Not protect module_put with spin_lock_irqsave", " - mfd: max14577: Fix wakeup source leaks on device unbind", " - sunrpc: don't immediately retransmit on seqno miss", " - leds: multicolor: Fix intensity setting while SW blinking", " - fuse: fix race between concurrent setattrs from multiple nodes", " - cxl/region: Add a dev_err() on missing target list entries", " - NFSv4: xattr handlers should check for absent nfs filehandles", " - hwmon: (pmbus/max34440) Fix support for max34451", " - ksmbd: allow a filename to contain special characters on SMB3.1.1 posix", " extension", " - ksmbd: provide zero as a unique ID to the Mac client", " - rust: module: place cleanup_module() in .exit.text section", " - dmaengine: xilinx_dma: Set dma_device directions", " - PCI: dwc: Make link training more robust by setting", " PORT_LOGIC_LINK_WIDTH to one lane", " - PCI: apple: Fix missing OF node reference in apple_pcie_setup_port", " - md/md-bitmap: fix dm-raid max_write_behind setting", " - amd/amdkfd: fix a kfd_process ref leak", " - iio: pressure: zpa2326: Use aligned_s64 for the timestamp", " - um: Add cmpxchg8b_emu and checksum functions to asm-prototypes.h", " - um: use proper care when taking mmap lock during segfault", " - coresight: Only check bottom two claim bits", " - usb: dwc2: also exit clock_gating when stopping udc while suspended", " - iio: adc: ad_sigma_delta: Fix use of uninitialized status_pos", " - usb: potential integer overflow in usbg_make_tpg()", " - usb: common: usb-conn-gpio: use a unique name for usb connector device", " - usb: Add checks for snprintf() calls in usb_alloc_dev()", " - usb: cdc-wdm: avoid setting WDM_READ for ZLP-s", " - usb: typec: displayport: Receive DP Status Update NAK request exit dp", " altmode", " - usb: typec: mux: do not return on EOPNOTSUPP in {mux, switch}_set", " - ALSA: hda: Ignore unsol events for cards being shut down", " - ALSA: hda: Add new pci id for AMD GPU display HD audio controller", " - ALSA: usb-audio: Add a quirk for Lenovo Thinkpad Thunderbolt 3 dock", " - ceph: fix possible integer overflow in ceph_zero_objects()", " - scsi: ufs: core: Don't perform UFS clkscaling during host async scan", " - ovl: Check for NULL d_inode() in ovl_dentry_upper()", " - fs/jfs: consolidate sanity checking in dbMount", " - ASoC: codecs: wcd9335: Handle nicer probe deferral and simplify with", " dev_err_probe()", " - ASoC: codec: wcd9335: Convert to GPIO descriptors", " - f2fs: don't over-report free space or inodes in statvfs", " - PCI: apple: Use helper function for_each_child_of_node_scoped()", " - PCI: apple: Set only available ports up", " - platform/x86: ideapad-laptop: move ACPI helpers from header to source", " file", " - platform/x86: ideapad-laptop: use usleep_range() for EC polling", " - i2c: tiny-usb: disable zero-length read messages", " - i2c: robotfuzz-osif: disable zero-length read messages", " - ASoC: amd: yc: Add DMI quirk for Lenovo IdeaPad Slim 5 15", " - attach_recursive_mnt(): do not lock the covering tree when sliding", " something under it", " - libbpf: Fix null pointer dereference in btf_dump__free on allocation", " failure", " - wifi: mac80211: fix beacon interval calculation overflow", " - af_unix: Don't set -ECONNRESET for consumed OOB skb.", " - vsock/uapi: fix linux/vm_sockets.h userspace compilation errors", " - um: ubd: Add missing error check in start_io_thread()", " - libbpf: Fix possible use-after-free for externs", " - net: enetc: Correct endianness handling in _enetc_rd_reg64", " - ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X507UAR", " - net: selftests: fix TCP packet checksum", " - drm/i915: fix build error some more", " - drm/bridge: ti-sn65dsi86: make use of debugfs_init callback", " - drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type", " - EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs", " - staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher()", " - dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive", " - serial: imx: Restore original RXTL for console to fix data loss", " - Bluetooth: L2CAP: Fix L2CAP MTU negotiation", " - dm-raid: fix variable in journal device check", " - btrfs: update superblock's device bytes_used when dropping chunk", " - net: libwx: fix the creation of page_pool", " - HID: lenovo: Restrict F7/9/11 mode to compact keyboards only", " - HID: wacom: fix memory leak on kobject creation failure", " - HID: wacom: fix memory leak on sysfs attribute creation failure", " - HID: wacom: fix kobject reference count leak", " - drm/ast: Fix comment on modeset lock", " - drm/cirrus-qemu: Fix pitch programming", " - drm/etnaviv: Protect the scheduler's pending list with its lock", " - drm/tegra: Assign plane type before registration", " - drm/udl: Unregister device before cleaning up on disconnect", " - drm/amdkfd: Fix race in GWS queue scheduling", " - drm/bridge: cdns-dsi: Fix the clock variable for mode_valid()", " - drm/bridge: cdns-dsi: Fix phy de-init and flag it so", " - drm/bridge: cdns-dsi: Fix connecting to next bridge", " - drm/bridge: cdns-dsi: Check return value when getting default PHY config", " - drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready", " - drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram", " - drm/amdgpu: Add kicker device detection", " - drm/amdgpu: switch job hw_fence to amdgpu_fence", " - ksmbd: Use unsafe_memcpy() for ntlm_negotiate", " - ksmbd: remove unsafe_memcpy use in session setup", " - media: uvcvideo: Rollback non processed entities on error", " - firmware: arm_scmi: Add a common helper to check if a message is", " supported", " - firmware: arm_scmi: Ensure that the message-id supports fastchannel", " - ARM: 9354/1: ptrace: Use bitfield helpers", " - nvme-tcp: fix I/O stalls on congested sockets", " - drm/amdgpu: seq64 memory unmap uses uninterruptible lock", " - 8250: microchip: pci1xxxx: Add PCIe Hot reset disable support for Rev C0", " and later devices", " - usb: gadget: f_hid: wake up readers on disable/unbind", " - drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1", " - Revert \"drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1\"", " - btrfs: fix qgroup reservation leak on failure to allocate ordered extent", " - smb: client: remove \\t from TP_printk statements", " - fs/proc/task_mmu: fix PAGE_IS_PFNZERO detection for the huge zero folio", " - drm/xe/display: Add check for alloc_ordered_workqueue()", " - ethernet: ionic: Fix DMA mapping tests", " - wifi: mac80211: Add link iteration macro for link data", " - wifi: mac80211: Create separate links for VLAN interfaces", " - wifi: mac80211: finish link init before RCU publish", " - netlink: specs: tc: replace underscores with dashes in names", " - drm/amdgpu/discovery: optionally use fw based ip discovery", " - drm/amd: Adjust output for discovery error handling", " - x86/traps: Initialize DR6 by writing its architectural reset value", " - serial: core: restore of_node information in sysfs", " - spi: spi-cadence-quadspi: Fix pm runtime unbalance", " - mm/gup: revert \"mm: gup: fix infinite loop within __get_longterm_locked\"", " - scsi: ufs: core: Fix clk scaling to be conditional in reset and restore", " - drm/amd/display: Correct non-OLED pre_T11_delay.", " - drm/xe/vm: move rebind_work init earlier", " - drm/xe/sched: stop re-submitting signalled jobs", " - drm/xe: Fix memset on iomem", " - drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTAL", " - drm/amdgpu: Fix SDMA UTC_L1 handling during start/stop sequences", " - drm/amd/display: Fix mpv playback corruption on weston", " - x86/fpu: Refactor xfeature bitmask update code for sigframe XSAVE", " - io_uring: fix potential page leak in io_sqe_buffer_register()", " - iio: dac: ad3552r: changes to use FIELD_PREP", " - drm/xe: Carve out wopcm portion from the stolen memory", " - usb: typec: tcpm: PSSourceOffTimer timeout in PR_Swap enters", " ERROR_RECOVERY", " - drm/msm/dp: account for widebus and yuv420 during mode validation", " - arm64: dts: rockchip: Add avdd HDMI supplies to RockPro64 board dtsi", " - ALSA: hda/realtek: Bass speaker fixup for ASUS UM5606KA", " - spi: fsl-qspi: Fix double cleanup in probe error path", " - Upstream stable to v6.6.96, v6.12.36", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-37842", " - spi: fsl-qspi: use devm function instead of driver remove", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-23155", " - net: stmmac: Fix accessing freed irq affinity_hint", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-22101", " - net: libwx: fix Tx L4 checksum", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38361", " - drm/amd/display: Check dce_hwseq before dereferencing it", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38364", " - maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38246", " - bnxt: properly flush XDP redirect lists", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38250", " - Bluetooth: hci_core: Fix use-after-free in vhci_flush()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38253", " - HID: wacom: fix crash in wacom_aes_battery_handler()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38264", " - nvme-tcp: sanitize request list handling", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38362", " - drm/amd/display: Add null pointer check for get_first_active_display()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38354", " - drm/msm/gpu: Fix crash when throttling GPU immediately during boot", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38363", " - drm/tegra: Fix a possible null pointer dereference", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38239", " - scsi: megaraid_sas: Fix invalid node index", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38365", " - btrfs: fix a race between renames and directory logging", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38244", " - smb: client: fix potential deadlock when reconnecting channels", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38245", " - atm: Release atm_dev_mutex after removing procfs in", " atm_dev_deregister().", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38249", " - ALSA: usb-audio: Fix out-of-bounds read in", " snd_usb_get_audioformat_uac3()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38251", " - atm: clip: prevent NULL deref in clip_push()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38255", " - lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38257", " - s390/pkey: Prevent overflow in size calculation for memdup_user()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38258", " - mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path", " on write", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38259", " - ASoC: codecs: wcd9335: Fix missing free of regulator supplies", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38230", " - jfs: validate AG parameters in dbMount() to prevent crashes", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38260", " - btrfs: handle csum tree error with rescue=ibadroots correctly", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38262", " - tty: serial: uartlite: register uart driver in init", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38368", " - misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38436", " - drm/scheduler: signal scheduled fence when kill job", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38263", " - bcache: fix NULL pointer in cache_set_flush()", "", " * Noble update: upstream stable patchset 2025-12-09 (LP: #2134499) //", " CVE-2025-38369", " - dmaengine: idxd: Check availability of workqueue allocated by idxd wq", " driver before using", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-22128", " - wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq()", " in error path", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38333", " - f2fs: fix to bail out in get_new_segment()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38210", " - configfs-tsm-report: Fix NULL dereference of tsm_ops", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38232", " - NFSD: fix race between nfsd registration and exports_proc", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38320", " - arm64/ptrace: Fix stack-out-of-bounds read in", " regs_get_kernel_stack_nth()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38424", " - perf: Fix sample vs do_exit()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38321", " - smb: Log an error when close_all_cached_dirs fails", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38180", " - net: atm: fix /proc/net/atm/lec handling", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38323", " - net: atm: add lec_mutex", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38181", " - calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38182", " - ublk: santizize the arguments from userspace when adding a device", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38183", " - net: lan743x: fix potential out-of-bounds write in", " lan743x_ptp_io_event_clock_get()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38184", " - tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38185", " - atm: atmtcp: Free invalid length skb in atmtcp_c_send().", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38324", " - mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38420", " - wifi: carl9170: do not ping device which has failed to load firmware", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38326", " - aoe: clean device rq_list in aoedev_downdev()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38089", " - sunrpc: handle SVC_GARBAGE during svc auth processing as auth error", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38084", " - mm/hugetlb: unshare page tables during VMA split, not before", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38190", " - atm: Revert atm_account_tx() if copy_from_iter_full() fails.", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38191", " - ksmbd: fix null pointer dereference in destroy_previous_session", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38192", " - net: clear the dst when changing skb protocol", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38193", " - net_sched: sch_sfq: reject invalid perturb period", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38328", " - jffs2: check jffs2_prealloc_raw_node_refs() result in few other places", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38194", " - jffs2: check that raw node were preallocated before writing summary", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38090", " - drivers/rapidio/rio_cm.c: prevent possible heap overwrite", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38197", " - platform/x86: dell_rbu: Fix list usage", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38198", " - fbcon: Make sure modelist not set on unregistered console", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38331", " - net: ethernet: cortina: Use TOE/TSO on all TCP", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38200", " - i40e: fix MMIO write access to an invalid page in i40e_clear_hw", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38332", " - scsi: lpfc: Use memcpy() for BIOS version", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38342", " - software node: Correct a OOB check in software_node_get_reference_args()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38334", " - x86/sgx: Prevent attempts to reclaim poisoned pages", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38425", " - i2c: tegra: check msg length in SMBUS block read", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38343", " - wifi: mt76: mt7996: drop fragments with multicast or broadcast RA", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38202", " - bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38422", " - net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38344", " - ACPICA: fix acpi parse and parseext cache leaks", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38345", " - ACPICA: fix acpi operand cache leak in dswstate.c", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38085", " - mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38208", " - smb: client: add NULL check in automount_fullpath", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38418", " - remoteproc: core: Release rproc->clean_table after rproc_attach() fails", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38419", " - remoteproc: core: Cleanup acquired resources when", " rproc_handle_resources() fails in rproc_attach()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38427", " - video: screen_info: Relocate framebuffers behind PCI bridges", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38086", " - net: ch9200: fix uninitialised access during mii_nway_restart", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38346", " - ftrace: Fix UAF when lookup kallsym after ftrace disabled", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38211", " - RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38212", " - ipc: fix to protect IPCS lookups using RCU", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38214", " - fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38215", " - fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38087", " - net/sched: fix use-after-free in taprio_dev_notifier", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38416", " - NFC: nci: uart: Set tty->disc_data only in success path", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38217", " - hwmon: (ftsteutates) Fix TOCTOU race in fts_read()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38218", " - f2fs: fix to do sanity check on sit_bitmap_size", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38219", " - f2fs: prevent kernel warning due to negative i_nlink from corrupted", " image", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38347", " - f2fs: fix to do sanity check on ino and xnid", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38428", " - Input: ims-pcu - check record size in ims_pcu_flash_firmware()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38220", " - ext4: only dirty folios when data journaling regular files", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38222", " - ext4: inline: fix len overflow in ext4_prepare_inline_data", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38336", " - ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38429", " - bus: mhi: ep: Update read pointer only after buffer is written", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38225", " - media: imx-jpeg: Cleanup after an allocation error", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38226", " - media: vivid: Change the siize of the composing", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38229", " - media: cxusb: no longer judge rbuf when the write fails", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38337", " - jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38338", " - fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38231", " - nfsd: Initialize ssc before laundromat_work to prevent NULL dereference", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38430", " - nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request", "", " * Noble update: upstream stable patchset 2025-12-08 (LP: #2134382) //", " CVE-2025-38348", " - wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786)", " - tracing: Fix compilation warning on arm32", " - pinctrl: armada-37xx: use correct OUTPUT_VAL register for GPIOs > 31", " - pinctrl: armada-37xx: set GPIO output value before setting direction", " - acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio()", " - rtc: Make rtc_time64_to_tm() support dates before 1970", " - rtc: Fix offset calculation for .start_secs < 0", " - usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE", " - usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage device", " - USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB", " - usb: typec: ucsi: fix Clang -Wsign-conversion warning", " - Bluetooth: hci_qca: move the SoC type check to the right place", " - usb: usbtmc: Fix timeout value in get_stb", " - dt-bindings: usb: cypress,hx3: Add support for all variants", " - dt-bindings: phy: imx8mq-usb: fix fsl,phy-tx-vboost-level-microvolt", " property", " - tools/x86/kcpuid: Fix error handling", " - x86/idle: Remove MFENCEs for X86_BUG_CLFLUSH_MONITOR in", " mwait_idle_with_hints() and prefer_mwait_c1_over_halt()", " - crypto: sun8i-ce-hash - fix error handling in sun8i_ce_hash_run()", " - gfs2: gfs2_create_inode error handling fix", " - perf/core: Fix broken throttling when max_samples_per_tick=1", " - crypto: sun8i-ss - do not use sg_dma_len before calling DMA functions", " - powerpc: do not build ppc_save_regs.o always", " - powerpc/crash: Fix non-smp kexec preparation", " - x86/microcode/AMD: Do not return error when microcode update is not", " necessary", " - x86/cpu: Sanitize CPUID(0x80000000) output", " - crypto: marvell/cesa - Avoid empty transfer descriptor", " - btrfs: scrub: update device stats when an error is detected", " - btrfs: scrub: fix a wrong error type when metadata bytenr mismatches", " - rcu/cpu_stall_cputime: fix the hardirq count for x86 architecture", " - crypto: lrw - Only add ecb if it is not already there", " - crypto: xts - Only add ecb if it is not already there", " - crypto: sun8i-ce - move fallback ahash_request to the end of the struct", " - kunit: Fix wrong parameter to kunit_deactivate_static_stub()", " - ACPICA: exserial: don't forget to handle FFixedHW opregions for reading", " - ASoC: tas2764: Enable main IRQs", " - EDAC/{skx_common,i10nm}: Fix the loss of saved RRL for HBM pseudo", " channel 0", " - spi: tegra210-quad: Fix X1_X2_X4 encoding and support x4 transfers", " - spi: tegra210-quad: remove redundant error handling code", " - spi: tegra210-quad: modify chip select (CS) deactivation", " - power: reset: at91-reset: Optimize at91_reset()", " - ASoC: SOF: ipc4-pcm: Adjust pipeline_list->pipelines allocation type", " - PM: wakeup: Delete space in the end of string shown by", " pm_show_wakelocks()", " - x86/mtrr: Check if fixed-range MTRRs exist in mtrr_save_fixed_ranges()", " - PM: sleep: Print PM debug messages during hibernation", " - ACPI: OSI: Stop advertising support for \"3.0 _SCP Extensions\"", " - spi: sh-msiof: Fix maximum DMA transfer size", " - ASoC: apple: mca: Constrain channels according to TDM mask", " - drm/vmwgfx: Add seqno waiter for sync_files", " - drm/vc4: tests: Use return instead of assert", " - media: rkvdec: Fix frame size enumeration", " - arm64/fpsimd: Avoid RES0 bits in the SME trap handler", " - arm64/fpsimd: Fix merging of FPSIMD state during signal return", " - drm/bridge: lt9611uxc: Fix an error handling path in lt9611uxc_probe()", " - watchdog: exar: Shorten identity name to fit correctly", " - m68k: mac: Fix macintosh_config for Mac II", " - firmware: psci: Fix refcount leak in psci_dt_init", " - arm64: Support ARM64_VA_BITS=52 when setting ARCH_MMAP_RND_BITS_MAX", " - selftests/seccomp: fix syscall_restart test for arm compat", " - drm: rcar-du: Fix memory leak in rcar_du_vsps_init()", " - drm/vkms: Adjust vkms_state->active_planes allocation type", " - drm/tegra: rgb: Fix the unbound reference count", " - firmware: SDEI: Allow sdei initialization without ACPI_APEI_GHES", " - arm64/fpsimd: Do not discard modified SVE state", " - scsi: qedf: Use designated initializer for struct qed_fcoe_cb_ops", " - drm/mediatek: mtk_drm_drv: Fix kobject put for mtk_mutex device ptr", " - drm/mediatek: Fix kobject put for component sub-drivers", " - drm/mediatek: mtk_drm_drv: Unbind secondary mmsys components on err", " - xen/x86: fix initial memory balloon target", " - IB/cm: use rwlock for MAD agent lock", " - selftests/bpf: Fix bpf_nf selftest failure", " - bpf, sockmap: fix duplicated data transmission", " - wifi: ath12k: Fix WMI tag for EHT rate in peer assoc", " - net: ncsi: Fix GCPS 64-bit member variables", " - libbpf: Fix buffer overflow in bpf_object__init_prog", " - xfrm: Use xdo.dev instead of xdo.real_dev", " - wifi: rtw88: sdio: map mgmt frames to queue TX_DESC_QSEL_MGMT", " - wifi: rtw88: sdio: call rtw_sdio_indicate_tx_status unconditionally", " - wifi: rtw88: do not ignore hardware read error during DPK", " - wifi: ath12k: Add MSDU length validation for TKIP MIC error", " - RDMA/hns: Include hnae3.h in hns_roce_hw_v2.h", " - scsi: hisi_sas: Call I_T_nexus after soft reset for SATA disk", " - libbpf: Remove sample_period init in perf_buffer", " - Use thread-safe function pointer in libbpf_print", " - iommu: Protect against overflow in iommu_pgsize()", " - bonding: assign random address if device address is same as bond", " - f2fs: clean up w/ fscrypt_is_bounce_page()", " - f2fs: fix to detect gcing page in f2fs_is_cp_guaranteed()", " - libbpf: Use proper errno value in linker", " - bpf: Allow XDP dev-bound programs to perform XDP_REDIRECT into maps", " - netfilter: bridge: Move specific fragmented packet to slow_path instead", " of dropping it", " - netfilter: nft_quota: match correctly when the quota just depleted", " - bpf: Fix uninitialized values in BPF_{CORE,PROBE}_READ", " - tracing: Move histogram trigger variables from stack to per CPU", " structure", " - clk: qcom: camcc-sm6350: Add *_wait_val values for GDSCs", " - clk: qcom: dispcc-sm6350: Add *_wait_val values for GDSCs", " - clk: qcom: gcc-sm6350: Add *_wait_val values for GDSCs", " - clk: qcom: gpucc-sm6350: Add *_wait_val values for GDSCs", " - efi/libstub: Describe missing 'out' parameter in efi_load_initrd", " - tracing: Rename event_trigger_alloc() to trigger_data_alloc()", " - tracing: Fix error handling in event_trigger_parse()", " - ktls, sockmap: Fix missing uncharge operation", " - libbpf: Use proper errno value in nlattr", " - clk: qcom: gcc-msm8939: Fix mclk0 & mclk1 for 24 MHz", " - s390/bpf: Store backchain even for leaf progs", " - iommu: remove duplicate selection of DMAR_TABLE", " - hisi_acc_vfio_pci: add eq and aeq interruption restore", " - scsi: ufs: mcq: Delete ufshcd_release_scsi_cmd() in ufshcd_mcq_abort()", " - wifi: mt76: mt7996: set EHT max ampdu length capability", " - wifi: mt76: mt7996: fix RX buffer size of MCU event", " - netfilter: nf_tables: nft_fib_ipv6: fix VRF ipv4/ipv6 result discrepancy", " - vfio/type1: Fix error unwind in migration dirty bitmap allocation", " - Bluetooth: MGMT: iterate over mesh commands in mgmt_mesh_foreach()", " - netfilter: nft_tunnel: fix geneve_opt dump", " - RISC-V: KVM: lock the correct mp_state during reset", " - RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work", " - net: lan966x: Fix 1-step timestamping over ipv4 or ipv6", " - net: phy: fix up const issues in to_mdio_device() and to_phy_device()", " - net: lan743x: rename lan743x_reset_phy to lan743x_hw_reset_phy", " - net: phy: mscc: Stop clearing the the UDPv4 checksum for L2 frames", " - f2fs: use d_inode(dentry) cleanup dentry->d_inode", " - f2fs: fix to correct check conditions in f2fs_cross_rename", " - arm64: dts: qcom: sdm845-starqltechn: remove wifi", " - arm64: dts: qcom: sdm845-starqltechn: fix usb regulator mistake", " - arm64: dts: qcom: sdm845-starqltechn: refactor node order", " - arm64: dts: qcom: sdm845-starqltechn: remove excess reserved gpios", " - arm64: dts: qcom: sm8350: Reenable crypto & cryptobam", " - arm64: dts: qcom: sm8250: Fix CPU7 opp table", " - arm64: dts: qcom: sc8280xp-x13s: Drop duplicate DMIC supplies", " - ARM: dts: at91: usb_a9263: fix GPIO for Dataflash chip select", " - ARM: dts: at91: at91sam9263: fix NAND chip selects", " - arm64: dts: mediatek: mt8195: Reparent vdec1/2 and venc1 power domains", " - arm64: dts: qcom: sdm660-xiaomi-lavender: Add missing SD card detect", " GPIO", " - arm64: dts: imx8mm-beacon: Fix RTC capacitive load", " - arm64: dts: imx8mn-beacon: Fix RTC capacitive load", " - arm64: dts: imx8mp-beacon: Fix RTC capacitive load", " - arm64: dts: imx8mm-beacon: Set SAI5 MCLK direction to output for HDMI", " audio", " - arm64: dts: imx8mn-beacon: Set SAI5 MCLK direction to output for HDMI", " audio", " - arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles", " - arm64: dts: mt6359: Add missing 'compatible' property to regulators node", " - arm64: dts: qcom: sdm660-lavender: Add missing USB phy supply", " - arm64: dts: qcom: sda660-ifc6560: Fix dt-validate warning", " - arm64: dts: rockchip: Update eMMC for NanoPi R5 series", " - arm64: tegra: Drop remaining serial clock-names and reset-names", " - arm64: dts: ti: k3-j721e-common-proc-board: Enable OSPI1 on J721E", " - ocfs2: fix possible memory leak in ocfs2_finish_quota_recovery", " - nilfs2: add pointer check for nilfs_direct_propagate()", " - nilfs2: do not propagate ENOENT error from nilfs_btree_propagate()", " - dt-bindings: vendor-prefixes: Add Liontron name", " - ARM: dts: qcom: apq8064: add missing clocks to the timer node", " - ARM: dts: qcom: apq8064 merge hw splinlock into corresponding syscon", " device", " - arm64: defconfig: mediatek: enable PHY drivers", " - arm64: dts: rockchip: disable unrouted USB controllers and PHY on RK3399", " Puma with Haikou", " - arm64: dts: renesas: white-hawk-ard-audio: Fix TPU0 groups", " - arm64: dts: mt6359: Rename RTC node to match binding expectations", " - ARM: aspeed: Don't select SRAM", " - soc: aspeed: lpc: Fix impossible judgment condition", " - randstruct: gcc-plugin: Remove bogus void member", " - randstruct: gcc-plugin: Fix attribute addition", " - perf build: Warn when libdebuginfod devel files are not available", " - perf ui browser hists: Set actions->thread before calling", " do_zoom_thread()", " - dm: don't change md if dm_table_set_restrictions() fails", " - dm: free table mempools if not used in __bind", " - dm-flakey: error all IOs when num_features is absent", " - dm-flakey: make corrupting read bios work", " - perf trace: Fix leaks of 'struct thread' in set_filter_loop_pids()", " - perf intel-pt: Fix PEBS-via-PT data_src", " - perf scripts python: exported-sql-viewer.py: Fix pattern matching with", " Python 3", " - remoteproc: qcom_wcnss_iris: Add missing put_device() on error in probe", " - remoteproc: k3-r5: Drop check performed in", " k3_r5_rproc_{mbox_callback/kick}", " - rpmsg: qcom_smd: Fix uninitialized return variable in __qcom_smd_send()", " - mfd: exynos-lpass: Avoid calling exynos_lpass_disable() twice in", " exynos_lpass_remove()", " - mfd: stmpe-spi: Correct the name used in MODULE_DEVICE_TABLE", " - perf tests switch-tracking: Fix timestamp comparison", " - perf record: Fix incorrect --user-regs comments", " - perf trace: Always print return value for syscalls returning a pid", " - nfs: clear SB_RDONLY before getting superblock", " - nfs: ignore SB_RDONLY when remounting nfs", " - cifs: Fix validation of SMB1 query reparse point response", " - rtc: sh: assign correct interrupts with DT", " - PCI: Print the actual delay time in pci_bridge_wait_for_secondary_bus()", " - PCI: cadence: Fix runtime atomic count underflow", " - PCI: apple: Use gpiod_set_value_cansleep in probe flow", " - PCI/DPC: Initialize aer_err_info before using it", " - rtc: loongson: Add missing alarm notifications for ACPI RTC events", " - thunderbolt: Fix a logic error in wake on connect", " - iio: filter: admv8818: fix band 4, state 15", " - iio: filter: admv8818: fix integer overflow", " - iio: filter: admv8818: fix range calculation", " - iio: filter: admv8818: Support frequencies >= 2^32", " - iio: adc: ad7124: Fix 3dB filter frequency reading", " - MIPS: Loongson64: Add missing '#interrupt-cells' for loongson64c_ls7a", " - counter: interrupt-cnt: Protect enable/disable OPs with mutex", " - vt: remove VT_RESIZE and VT_RESIZEX from vt_compat_ioctl()", " - net: stmmac: platform: guarantee uniqueness of bus_id", " - gve: Fix RX_BUFFERS_POSTED stat to report per-queue fill_cnt", " - net: tipc: fix refcount warning in tipc_aead_encrypt", " - driver: net: ethernet: mtk_star_emac: fix suspend/resume issue", " - net/mlx4_en: Prevent potential integer overflow calculating Hz", " - net: lan966x: Make sure to insert the vlan tags also in host mode", " - spi: bcm63xx-spi: fix shared reset", " - spi: bcm63xx-hsspi: fix shared reset", " - Bluetooth: L2CAP: Fix not responding with L2CAP_CR_LE_ENCRYPTION", " - ice: create new Tx scheduler nodes for new queues only", " - ice: fix rebuilding the Tx scheduler tree for large queue counts", " - net: dsa: tag_brcm: legacy: fix pskb_may_pull length", " - vmxnet3: correctly report gso type for UDP tunnels", " - PM: sleep: Fix power.is_suspended cleanup for direct-complete devices", " - netfilter: nf_nat: also check reverse tuple to obtain clashing entry", " - net: dsa: b53: do not enable RGMII delay on bcm63xx", " - net: dsa: b53: allow RGMII for bcm63xx RGMII ports", " - wireguard: device: enable threaded NAPI", " - scsi: ufs: qcom: Prevent calling phy_exit() before phy_init()", " - ASoC: codecs: hda: Fix RPM usage count underflow", " - ASoC: Intel: avs: Fix deadlock when the failing IPC is SET_D0IX", " - ASoC: ti: omap-hdmi: Re-add dai_link->platform to fix card init", " - path_overmount(): avoid false negatives", " - fix propagation graph breakage by MOVE_MOUNT_SET_GROUP move_mount(2)", " - Input: synaptics-rmi - fix crash with unsupported versions of F34", " - arm64: dts: ti: k3-j721e-sk: Add DT nodes for power regulators", " - serial: sh-sci: Move runtime PM enable to sci_probe_single()", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Bluetooth: hci_core: fix list_for_each_entry_rcu usage", " - Bluetooth: MGMT: Remove unused mgmt_pending_find_data", " - ath10k: snoc: fix unbalanced IRQ enable in crash recovery", " - wifi: ath11k: fix soc_dp_stats debugfs file permission", " - wifi: ath11k: convert timeouts to secs_to_jiffies()", " - wifi: ath11k: avoid burning CPU in ath11k_debugfs_fw_stats_request()", " - wifi: ath11k: don't use static variables in", " ath11k_debugfs_fw_stats_process()", " - wifi: ath11k: don't wait when there is no vdev started", " - wifi: ath11k: validate ath11k_crypto_mode on top of", " ath11k_core_qmi_firmware_ready", " - regulator: max20086: Fix refcount leak in max20086_parse_regulators_dt()", " - pinctrl: qcom: pinctrl-qcm2290: Add missing pins", " - scsi: iscsi: Fix incorrect error path labels for flashnode operations", " - powerpc/vas: Return -EINVAL if the offset is non-zero in mmap()", " - drm/meson: use unsigned long long / Hz for frequency types", " - drm/meson: fix debug log statement when setting the HDMI clocks", " - drm/meson: use vclk_freq instead of pixel_freq in debug print", " - drm/meson: fix more rounding issues with 59.94Hz modes", " - i40e: return false from i40e_reset_vf if reset is in progress", " - i40e: retry VFLR handling if there is ongoing VF reset", " - macsec: MACsec SCI assignment for ES = 0", " - Bluetooth: hci_sync: Fix broadcast/PA when using an existing instance", " - net/mlx5: Ensure fw pages are always allocated on same NUMA", " - net/mlx5: Fix return value when searching for existing flow group", " - net/mlx5e: Fix leak of Geneve TLV option object", " - net_sched: tbf: fix a race in tbf_change()", " - fs/filesystems: Fix potential unsigned integer underflow in fs_name()", " - nvmet-fcloop: access fcpreq only when holding reqlock", " - perf: Ensure bpf_perf_link path is properly serialized", " - bio: Fix bio_first_folio() for SPARSEMEM without VMEMMAP", " - block: Fix bvec_set_folio() for very large folios", " - tools/resolve_btfids: Fix build when cross compiling kernel with clang.", " - ALSA: usb-audio: Add implicit feedback quirk for RODE AI-1", " - io_uring: expand main struct io_kiocb flags to 64-bits", " - io_uring: add io_file_can_poll() helper", " - io_uring/rw: allow pollable non-blocking attempts for !FMODE_NOWAIT", " - io_uring/rw: fix wrong NOWAIT check in io_rw_init_file()", " - usb: usbtmc: Fix read_stb function and get_stb ioctl", " - usb: cdnsp: Fix issue with detecting command completion event", " - usb: cdnsp: Fix issue with detecting USB 3.2 speed", " - usb: Flush altsetting 0 endpoints before reinitializating them after", " reset.", " - usb: typec: tcpm/tcpci_maxim: Fix bounds check in process_rx()", " - xen/arm: call uaccess_ttbr0_enable for dm_op hypercall", " - calipso: unlock rcu before returning -EAFNOSUPPORT", " - regulator: dt-bindings: mt6357: Drop fixed compatible requirement", " - net: usb: aqc111: debug info before sanitation", " - drm/meson: Use 1000ULL when operating with mode->clock", " - Documentation: ACPI: Use all-string data node references", " - PCI/ASPM: Consolidate link state defines", " - PCI/ASPM: Disable L1 before disabling L1 PM Substates", " - perf/x86/amd/uncore: Remove unused 'struct amd_uncore_ctx::node' member", " - perf/x86/amd/uncore: Prevent UMC counters from saturating", " - crypto: sun8i-ce - undo runtime PM changes during driver removal", " - erofs: fix file handle encoding for 64-bit NIDs", " - btrfs: fix invalid data space release when truncating block in NOCOW", " mode", " - ACPI: resource: fix a typo for MECHREVO in", " irq1_edge_low_force_override[]", " - thermal/drivers/mediatek/lvts: Fix debugfs unregister on failure", " - drm/vmwgfx: Add error path for xa_store in vmw_bo_add_detached_resource", " - drm/vmwgfx: Fix dumb buffer leak", " - drm/xe/d3cold: Set power state to D3Cold during s2idle/s3", " - drm/panel: samsung-sofef00: Drop s6e3fc2x01 support", " - kunit/usercopy: Disable u64 test on 32-bit SPARC", " - drm/msm/dpu: enable SmartDMA on SM8150", " - drm/msm/dpu: enable SmartDMA on SC8180X", " - overflow: Fix direct struct member initialization in _DEFINE_FLEX()", " - drm/msm/a6xx: Disable rgb565_predicator on Adreno 7c3", " - media: verisilicon: Free post processor buffers on error", " - wifi: ath12k: Fix memory leak during vdev_id mismatch", " - wifi: ath12k: Fix invalid memory access while forming 802.11 header", " - bpf: Check link_create.flags parameter for multi_kprobe", " - wifi: ath12k: fix cleanup path after mhi init", " - f2fs: clean up unnecessary indentation", " - f2fs: prevent the current section from being selected as a victim during", " GC", " - net/mlx5: Avoid using xso.real_dev unnecessarily", " - wifi: ath12k: Fix the QoS control field offset to build QoS header", " - libbpf: Fix event name too long error", " - wifi: iwlfiwi: mvm: Fix the rate reporting", " - selftests/bpf: Fix caps for __xlated/jited_unpriv", " - wifi: rtw89: pci: enlarge retry times of RX tag to 1000", " - wifi: mt76: mt7925: prevent multiple scan commands", " - wifi: mt76: mt7925: refine the sniffer commnad", " - wifi: mt76: mt7925: ensure all MCU commands wait for response", " - netfilter: nf_tables: nft_fib: consistent l3mdev handling", " - vsock/virtio: fix `rx_bytes` accounting for stream sockets", " - net: xilinx: axienet: Fix Tx skb circular buffer occupancy check in", " dmaengine xmit", " - net: lan743x: Fix PHY reset handling during initialization and WOL", " - octeontx2-af: Sync NIX and NPA contexts from NDC to LLC/DRAM", " - octeontx2-pf: QOS: Perform cache sync on send queue teardown", " - arm64: dts: qcom: sm8650: add missing cpu-cfg interconnect path in the", " mdss node", " - arm64: dts: qcom: ipq9574: Fix USB vdd info", " - arm64: dts: rockchip: Move SHMEM memory to reserved memory on rk3588", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Simplify DSI endpoint", " replacement", " - arm64: dts: mt8183: Add port node to mt8183.dtsi", " - soc: qcom: smp2p: Fix fallback to qcom,ipc parse", " - ARM: dts: qcom: apq8064: move replicator out of soc node", " - arm64: dts: qcom: qcm2290: fix (some) of QUP interconnects", " - perf symbol-minimal: Fix double free in filename__read_build_id", " - mfd: exynos-lpass: Fix an error handling path in exynos_lpass_probe()", " - mailbox: imx: Fix TXDB_V2 sending", " - mailbox: mtk-cmdq: Refine GCE_GCTL_VALUE setting", " - perf symbol: Fix use-after-free in filename__read_build_id", " - PCI/DPC: Log Error Source ID only when valid", " - coresight: catu: Introduce refcount and spinlock for enabling/disabling", " - mei: vsc: Cast tx_buf to (__be32 *) when passed to cpu_to_be32_array()", " - iio: adc: mcp3911: fix device dependent mappings for conversion result", " registers", " - drm/xe: Make xe_gt_freq part of the Documentation", " - Fix sock_exceed_buf_limit not being triggered in", " __sk_mem_raise_allocated", " - idpf: fix netdev Tx queue stop/wake", " - idpf: fix a race in txq wakeup", " - nvme: fix command limits status code", " - drm/panel-simple: fix the warnings for the Evervision VGG644804", " - net: ti: icssg-prueth: Fix swapped TX stats for MII interfaces.", " - net: dsa: b53: Introduce b53_adjust_531x5_rgmii()", " - net: dsa: b53: do not touch DLL_IQQD on bcm53115", " - ALSA: hda/realtek: fix micmute LEDs on HP Laptops with ALC3315", " - ALSA: hda/realtek: fix micmute LEDs on HP Laptops with ALC3247", " - ALSA: hda/realtek: Add support for various HP Laptops using CS35L41 HDA", " - ALSA: hda/realtek - Support mute led function for HP platform", " - ALSA: hda/realtek - Add new HP ZBook laptop with micmute led fixup", " - ALSA: hda/realtek: Add support for HP Agusta using CS35L41 HDA", " - dt-bindings: pinctrl: samsung: google,gs101-pinctrl needs a clock", " - pinctrl: samsung: support a bus clock", " - pinctrl: samsung: refactor drvdata suspend & resume callbacks", " - pinctrl: samsung: add dedicated SoC eint suspend/resume callbacks", " - pinctrl: samsung: add gs101 specific eint suspend/resume callbacks", " - net: dsa: b53: fix untagged traffic sent via cpu tagged with VID 0", " - wifi: ath11k: move some firmware stats related functions outside of", " debugfs", " - wifi: ath12k: refactor ath12k_hw_regs structure", " - gfs2: pass through holder from the VFS for freeze/thaw", " - btrfs: exit after state split error at set_extent_bit()", " - block: use q->elevator with ->elevator_lock held in elv_iosched_show()", " - 9p: Add a migrate_folio method", " - overflow: Introduce __DEFINE_FLEX for having no initializer", " - thermal/drivers/mediatek/lvts: Remove unused lvts_debugfs_exit", " - Upstream stable to v6.6.94, v6.12.33, v6.12.34", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38101", " - ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38269", " - btrfs: exit after state insertion failure at btrfs_convert_extent_bit()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38303", " - Bluetooth: eir: Fix possible crashes on eir_create_adv_data", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38414", " - wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38125", " - net: stmmac: make sure that ptp_rate is not 0 before configuring EST", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38129", " - page_pool: Fix use-after-free in page_pool_recycle_in_ring", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38156", " - wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38162", " - netfilter: nft_set_pipapo: prevent overflow in lookup table allocation", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38292", " - wifi: ath12k: fix invalid access to memory", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38164", " - f2fs: zone: fix to avoid inconsistence in between SIT and SSA", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38169", " - arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38299", " - ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38100", " - x86/iopl: Cure TIF_IO_BITMAP inconsistencies", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38102", " - VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38103", " - HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38107", " - net_sched: ets: fix a race in ets_qdisc_change()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38108", " - net_sched: red: fix a race in __red_change()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38109", " - net/mlx5: Fix ECVF vports unload on shutdown flow", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38304", " - Bluetooth: Fix NULL pointer deference on eir_get_service_data", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38110", " - net/mdiobus: Fix potential out-of-bounds clause 45 read/write access", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38111", " - net/mdiobus: Fix potential out-of-bounds read/write access", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38112", " - net: Fix TOCTOU issue in sk_is_readable()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38113", " - ACPI: CPPC: Fix NULL pointer dereference when nosmp is used", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38088", " - powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38115", " - net_sched: sch_sfq: fix a potential crash on gso_skb handling", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38305", " - ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38117", " - Bluetooth: MGMT: Protect mgmt_pending list with its own lock", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38119", " - scsi: core: ufs: Fix a hang in the error handler", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38307", " - ASoC: Intel: avs: Verify content returned by parse_int_array()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38310", " - seg6: Fix validation of nexthop addresses", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38120", " - netfilter: nf_set_pipapo_avx2: fix initial map fill", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38122", " - gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38123", " - net: wwan: t7xx: Fix napi rx poll issue", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38124", " - net: fix udp gso skb_segment after pull from frag_list", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38126", " - net: stmmac: make sure that ptp_rate is not 0 before configuring", " timestamping", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38127", " - ice: fix Tx scheduler error handling in XDP callback", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38131", " - coresight: prevent deactivate active config while enabling the config", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38274", " - fpga: fix potential null pointer deref in fpga_mgr_test_img_load_sgt()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38135", " - serial: Fix potential null-ptr-deref in mlb_usio_probe()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38136", " - usb: renesas_usbhs: Reorder clock handling and power management in probe", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38138", " - dmaengine: ti: Add NULL check in udma_probe()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38275", " - phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38142", " - hwmon: (asus-ec-sensors) check sensor index in read_string()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38277", " - mtd: nand: ecc-mxic: Fix use of uninitialized variable ret", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38143", " - backlight: pm8941: Add NULL check in wled_configure()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38312", " - fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38145", " - soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38313", " - bus: fsl-mc: fix double-free on mc_dev", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38415", " - Squashfs: check return result of sb_min_blocksize", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38146", " - net: openvswitch: Fix the dead loop of MPLS parse", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38147", " - calipso: Don't call calipso functions for AF_INET sk.", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38278", " - octeontx2-pf: QOS: Refactor TC_HTB_LEAF_DEL_LAST callback", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38148", " - net: phy: mscc: Fix memory leak when using one step timestamping", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38149", " - net: phy: clear phydev->devlink when the link is deleted", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38280", " - bpf: Avoid __bpf_prog_ret0_warn when jit fails", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38153", " - net: usb: aqc111: fix error handling of usbnet read calls", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38154", " - bpf, sockmap: Avoid using sk_socket after free when sending", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38155", " - wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38282", " - kernfs: Relax constraint in draining guard", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38157", " - wifi: ath9k_htc: Abort software beacon handling if disabled", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38283", " - hisi_acc_vfio_pci: bugfix live migration function without VF device", " driver", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38158", " - hisi_acc_vfio_pci: fix XQE dma address error", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-39890", " - wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38159", " - wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38285", " - bpf: Fix WARN() in get_bpf_raw_tp_regs", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38286", " - pinctrl: at91: Fix possible out-of-boundary access", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38160", " - clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38161", " - RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38290", " - wifi: ath12k: fix node corruption in ar->arvifs list", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38163", " - f2fs: fix to do sanity check on sbi->total_valid_block_count", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38165", " - bpf, sockmap: Fix panic when calling skb_linearize", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38166", " - bpf: fix ktls panic with sockmap", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38293", " - wifi: ath11k: fix node corruption in ar->arvifs list", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38295", " - perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in", " meson_ddr_pmu_create()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38167", " - fs/ntfs3: handle hdr_first_de() return value", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38170", " - arm64/fpsimd: Discard stale CPU state when handling SME traps", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38319", " - drm/amd/pp: Fix potential NULL pointer dereference in", " atomctrl_initialize_mc_reg_table", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38298", " - EDAC/skx_common: Fix general protection fault", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38173", " - crypto: marvell/cesa - Handle zero-length skcipher requests", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38300", " - crypto: sun8i-ce-cipher - fix error handling in", " sun8i_ce_cipher_prepare()", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38174", " - thunderbolt: Do not double dequeue a configuration request", "", " * Noble update: upstream stable patchset 2025-12-03 (LP: #2133786) //", " CVE-2025-38265", " - serial: jsm: fix NPE during jsm_uart_port_init", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301)", " - i2c: designware: Uniform initialization flow for polling mode", " - i2c: designware: Remove ->disable() callback", " - i2c: designware: Use temporary variable for struct device", " - i2c: designware: Fix an error handling path in i2c_dw_pci_probe()", " - phy: renesas: rcar-gen3-usb2: Add support to initialize the bus", " - phy: renesas: rcar-gen3-usb2: Move IRQ request in probe", " - phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver", " data", " - phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off", " - cpufreq: Add SM8650 to cpufreq-dt-platdev blocklist", " - nvmem: rockchip-otp: Move read-offset into variant-data", " - nvmem: rockchip-otp: add rk3576 variant data", " - nvmem: core: verify cell's raw_len", " - nvmem: core: update raw_len if the bit reading is required", " - nvmem: qfprom: switch to 4-byte aligned reads", " - scsi: ufs: Introduce quirk to extend PA_HIBERN8TIME for UFS devices", " - intel_th: avoid using deprecated page->mapping, index fields", " - dma-mapping: avoid potential unused data compilation warning", " - cgroup: Fix compilation issue due to cgroup_mutex not being exported", " - scsi: mpi3mr: Add level check to control event logging", " - net: enetc: refactor bulk flipping of RX buffers to separate function", " - ima: process_measurement() needlessly takes inode_lock() on MAY_READ", " - drm/amdgpu: Allow P2P access through XGMI", " - selftests/bpf: Mitigate sockmap_ktls disconnect_after_delete failure", " - bpf: fix possible endless loop in BPF map iteration", " - samples/bpf: Fix compilation failure for samples/bpf on LoongArch Fedora", " - kconfig: merge_config: use an empty file as initfile", " - s390/vfio-ap: Fix no AP queue sharing allowed message written to kernel", " log", " - cifs: Add fallback for SMB2 CREATE without FILE_READ_ATTRIBUTES", " - cifs: Fix querying and creating MF symlinks over SMB1", " - cifs: Fix negotiate retry functionality", " - smb: client: Store original IO parameters and prevent zero IO sizes", " - fuse: Return EPERM rather than ENOSYS from link()", " - NFSv4: Check for delegation validity in", " nfs_start_delegation_return_locked()", " - NFS: Don't allow waiting for exiting tasks", " - arm64: Add support for HIP09 Spectre-BHB mitigation", " - tracing: Mark binary printing functions with __printf() attribute", " - ACPI: PNP: Add Intel OC Watchdog IDs to non-PNP device list", " - mailbox: pcc: Use acpi_os_ioremap() instead of ioremap()", " - mailbox: use error ret code of of_parse_phandle_with_args()", " - riscv: Allow NOMMU kernels to access all of RAM", " - fbdev: fsl-diu-fb: add missing device_remove_file()", " - fbcon: Use correct erase colour for clearing in fbcon", " - fbdev: core: tileblit: Implement missing margin clearing for tileblit", " - cifs: add validation check for the fields in smb_aces", " - cifs: Fix establishing NetBIOS session for SMB2+ connection", " - NFSv4: Treat ENETUNREACH errors as fatal for state recovery", " - SUNRPC: rpc_clnt_set_transport() must not change the autobind setting", " - SUNRPC: rpcbind should never reset the port to the value '0'", " - thermal/drivers/qoriq: Power down TMU on system suspend", " - dql: Fix dql->limit value when reset.", " - lockdep: Fix wait context check on softirq for PREEMPT_RT", " - objtool: Properly disable uaccess validation", " - PCI: dwc: ep: Ensure proper iteration over outbound map windows", " - tools/build: Don't pass test log files to linker", " - pNFS/flexfiles: Report ENETDOWN as a connection error", " - PCI: vmd: Disable MSI remapping bypass under Xen", " - ext4: on a remount, only log the ro or r/w state when it has changed", " - mmc: host: Wait for Vdd to settle on card power off", " - wifi: mt76: only mark tx-status-failed frames as ACKed on mt76x0/2", " - wifi: mt76: mt7996: revise TXS size", " - x86/stackprotector/64: Only export __ref_stack_chk_guard on CONFIG_SMP", " - i2c: qup: Vote for interconnect bandwidth to DRAM", " - i2c: pxa: fix call balance of i2c->clk handling routines", " - btrfs: make btrfs_discard_workfn() block_group ref explicit", " - btrfs: avoid linker error in btrfs_find_create_tree_block()", " - btrfs: run btrfs_error_commit_super() early", " - btrfs: fix non-empty delayed iputs list on unmount due to async workers", " - btrfs: get zone unusable bytes while holding lock at", " btrfs_reclaim_bgs_work()", " - btrfs: send: return -ENAMETOOLONG when attempting a path that is too", " long", " - drm/amd/display: Guard against setting dispclk low for dcn31x", " - i3c: master: svc: Fix missing STOP for master request", " - dlm: make tcp still work in multi-link env", " - um: Store full CSGSFS and SS register from mcontext", " - um: Update min_low_pfn to match changes in uml_reserved", " - ext4: reorder capability check last", " - hypfs_create_cpu_files(): add missing check for hypfs_mkdir() failure", " - scsi: st: Tighten the page format heuristics with MODE SELECT", " - scsi: st: ERASE does not change tape location", " - vfio/pci: Handle INTx IRQ_NOTCONNECTED", " - bpf: Return prog btf_id without capable check", " - jbd2: do not try to recover wiped journal", " - tcp: reorganize tcp_in_ack_event() and tcp_count_delivered()", " - rtc: rv3032: fix EERD location", " - thunderbolt: Do not add non-active NVM if NVM upgrade is disabled for", " retimer", " - ASoC: mediatek: mt6359: Add stub for mt6359_accdet_enable_jack_detect", " - bpf: Allow pre-ordering for bpf cgroup progs", " - kbuild: fix argument parsing in scripts/config", " - crypto: octeontx2 - suppress auth failure screaming due to negative", " tests", " - dm: restrict dm device size to 2^63-512 bytes", " - net/smc: use the correct ndev to find pnetid by pnetid table", " - xen: Add support for XenServer 6.1 platform device", " - pinctrl-tegra: Restore SFSEL bit when freeing pins", " - mfd: tps65219: Remove TPS65219_REG_TI_DEV_ID check", " - drm/amdgpu: Update SRIOV video codec caps", " - ASoC: sun4i-codec: support hp-det-gpios property", " - ext4: reject the 'data_err=abort' option in nojournal mode", " - ext4: do not convert the unwritten extents if data writeback fails", " - RDMA/uverbs: Propagate errors from rdma_lookup_get_uobject()", " - posix-timers: Add cond_resched() to posix_timer_add() search loop", " - timer_list: Don't use %pK through printk()", " - netfilter: conntrack: Bound nf_conntrack sysctl writes", " - arm64/mm: Check PUD_TYPE_TABLE in pud_bad()", " - mmc: dw_mmc: add exynos7870 DW MMC support", " - usb: xhci: Don't change the status of stalled TDs on failed Stop EP", " - hwmon: (dell-smm) Increment the number of fans", " - printk: Check CON_SUSPEND when unblanking a console", " - drm/amd/display: remove minimum Dispclk and apply oem panel timing.", " - drm/amd/display: calculate the remain segments for all pipes", " - drm/amd/display: Fix incorrect DPCD configs while Replay/PSR switch", " - gfs2: Check for empty queue in run_queue", " - auxdisplay: charlcd: Partially revert \"Move hwidth and bwidth to struct", " hd44780_common\"", " - ASoC: qcom: sm8250: explicitly set format in sm8250_be_hw_params_fixup()", " - iommu/amd/pgtbl_v2: Improve error handling", " - watchdog: aspeed: Update bootstatus handling", " - drm/amdkfd: Set per-process flags only once cik/vi", " - arm64: tegra: p2597: Fix gpio for vdd-1v8-dis regulator", " - arm64: tegra: Resize aperture for the IGX PCIe C5 slot", " - powerpc/prom_init: Fixup missing #size-cells on PowerBook6,7", " - ALSA: seq: Improve data consistency at polling", " - tcp: bring back NUMA dispersion in inet_ehash_locks_alloc()", " - rtc: ds1307: stop disabling alarms on probe", " - ieee802154: ca8210: Use proper setters and getters for bitwise types", " - ARM: tegra: Switch DSI-B clock parent to PLLD on Tegra114", " - media: c8sectpfe: Call of_node_put(i2c_bus) only once in", " c8sectpfe_probe()", " - drm/gem: Test for imported GEM buffers with helper", " - net: phylink: use pl->link_interface in phylink_expects_phy()", " - remoteproc: qcom_wcnss: Handle platforms with only single power domain", " - drm/amdgpu: Do not program AGP BAR regs under SRIOV in gfxhub_v1_0.c", " - drm/amd/display: Skip checking FRL_MODE bit for PCON BW determination", " - pinctrl: bcm281xx: Use \"unsigned int\" instead of bare \"unsigned\"", " - net: ethernet: ti: cpsw_new: populate netdev of_node", " - net: pktgen: fix mpls maximum labels list parsing", " - perf/hw_breakpoint: Return EOPNOTSUPP for unsupported breakpoint type", " - ALSA: hda/realtek: Enable PC beep passthrough for HP EliteBook 855 G7", " - ipv4: fib: Move fib_valid_key_len() to rtm_to_fib_config().", " - drm/rockchip: vop2: Add uv swap for cluster window", " - media: uvcvideo: Add sanity check to uvc_ioctl_xu_ctrl_map", " - media: uvcvideo: Handle uvc menu translation inside uvc_get_le_value", " - clk: imx8mp: inform CCF of maximum frequency of clocks", " - hwmon: (gpio-fan) Add missing mutex locks", " - ARM: at91: pm: fix at91_suspend_finish for ZQ calibration", " - drm/mediatek: mtk_dpi: Add checks for reg_h_fre_con existence", " - fpga: altera-cvp: Increase credit timeout", " - perf: arm_pmuv3: Call kvm_vcpu_pmu_resync_el0() before enabling counters", " - soc: apple: rtkit: Use high prio work queue", " - soc: apple: rtkit: Implement OSLog buffers properly", " - wifi: ath12k: Report proper tx completion status to mac80211", " - PCI: brcmstb: Expand inbound window size up to 64GB", " - PCI: brcmstb: Add a softdep to MIP MSI-X driver", " - net/mlx5: Avoid report two health errors on same syndrome", " - selftests/net: have `gro.sh -t` return a correct exit code", " - drm/amdkfd: KFD release_work possible circular locking", " - leds: pwm-multicolor: Add check for fwnode_property_read_u32", " - net: ethernet: mtk_ppe_offload: Allow QinQ, double ETH_P_8021Q only", " - net: xgene-v2: remove incorrect ACPI_PTR annotation", " - bonding: report duplicate MAC address in all situations", " - wifi: ath12k: Improve BSS discovery with hidden SSID in 6 GHz band", " - soc: ti: k3-socinfo: Do not use syscon helper to build regmap", " - Octeontx2-af: RPM: Register driver with PCI subsys IDs", " - x86/build: Fix broken copy command in genimage.sh when making isoimage", " - drm/amd/display: handle max_downscale_src_width fail check", " - ASoC: mediatek: mt8188: Treat DMIC_GAINx_CUR as non-volatile", " - ASoC: mediatek: mt8188: Add reference for dmic clocks", " - x86/nmi: Add an emergency handler in nmi_desc & use it in", " nmi_shootdown_cpus()", " - vhost-scsi: Return queue full for page alloc failures during copy", " - vdpa/mlx5: Fix mlx5_vdpa_get_config() endianness on big-endian machines", " - media: adv7180: Disable test-pattern control on adv7180", " - media: tc358746: improve calculation of the D-PHY timing registers", " - libbpf: Fix out-of-bound read", " - net/mlx5: Change POOL_NEXT_SIZE define value and make it global", " - crypto: ahash - Set default reqsize from ahash_alg", " - crypto: skcipher - Zap type in crypto_alloc_sync_skcipher", " - MIPS: Use arch specific syscall name match function", " - MIPS: pm-cps: Use per-CPU variables as per-CPU, not per-core", " - clocksource: mips-gic-timer: Enable counter when CPUs start", " - scsi: mpt3sas: Send a diag reset if target reset fails", " - wifi: rtw88: Fix rtw_init_vht_cap() for RTL8814AU", " - wifi: rtw88: Fix rtw_init_ht_cap() for RTL8814AU", " - wifi: rtw88: Fix rtw_desc_to_mcsrate() to handle MCS16-31", " - wifi: rtw89: fw: propagate error code from rtw89_h2c_tx()", " - EDAC/ie31200: work around false positive build warning", " - i3c: master: svc: Flush FIFO before sending Dynamic Address", " Assignment(DAA)", " - drm/amd/display: Add support for disconnected eDP streams", " - RDMA/core: Fix best page size finding when it can cross SG entries", " - pmdomain: imx: gpcv2: use proper helper for property detection", " - can: c_can: Use of_property_present() to test existence of DT property", " - bpf: don't do clean_live_states when state->loop_entry->branches > 0", " - eth: mlx4: don't try to complete XDP frames in netpoll", " - PCI: Fix old_size lower bound in calculate_iosize() too", " - ACPI: HED: Always initialize before evged", " - vxlan: Join / leave MC group after remote changes", " - media: test-drivers: vivid: don't call schedule in loop", " - net/mlx5: Modify LSB bitmask in temperature event to include only the", " first bit", " - net/mlx5: Apply rate-limiting to high temperature warning", " - firmware: arm_ffa: Reject higher major version as incompatible", " - ASoC: ops: Enforce platform maximum on initial value", " - ASoC: tas2764: Add reg defaults for TAS2764_INT_CLK_CFG", " - ASoC: tas2764: Mark SW_RESET as volatile", " - ASoC: tas2764: Power up/down amp on mute ops", " - ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot()", " - pinctrl: devicetree: do not goto err when probing hogs in", " pinctrl_dt_to_map", " - smack: recognize ipv4 CIPSO w/o categories", " - smack: Revert \"smackfs: Added check catlen\"", " - kunit: tool: Use qboot on QEMU x86_64", " - media: i2c: imx219: Correct the minimum vblanking value", " - media: v4l: Memset argument to 0 before calling get_mbus_config pad op", " - net/mlx4_core: Avoid impossible mlx4_db_alloc() order value", " - clk: qcom: ipq5018: allow it to be bulid on arm32", " - [Config] clk: qcom: ipq5018: enable module on armhf", " - clk: qcom: clk-alpha-pll: Do not use random stack value for recalc rate", " - x86/traps: Cleanup and robustify decode_bug()", " - sched: Reduce the default slice to avoid tasks getting an extra tick", " - serial: sh-sci: Update the suspend/resume support", " - phy: core: don't require set_mode() callback for phy_get_mode() to work", " - soundwire: amd: change the soundwire wake enable/disable sequence", " - drm/amdgpu: Set snoop bit for SDMA for MI series", " - drm/amd/display: Don't try AUX transactions on disconnected link", " - drm/amdgpu: reset psp->cmd to NULL after releasing the buffer", " - drm/amd/display: Update CR AUX RD interval interpretation", " - drm/amd/display: Initial psr_version with correct setting", " - drm/amdgpu: enlarge the VBIOS binary size limit", " - drm/amd/display/dm: drop hw_support check in amdgpu_dm_i2c_xfer()", " - scsi: target: spc: Fix loop traversal in spc_rsoc_get_descr()", " - net/mlx5: Extend Ethtool loopback selftest to support non-linear SKB", " - net/mlx5e: set the tx_queue_len for pfifo_fast", " - net/mlx5e: reduce rep rxq depth to 256 for ECPF", " - net/mlx5e: reduce the max log mpwrq sz for ECPF and reps", " - drm/v3d: Add clock handling", " - wifi: mac80211: don't unconditionally call drv_mgd_complete_tx()", " - wifi: mac80211: remove misplaced drv_mgd_complete_tx() call", " - net: fec: Refactor MAC reset to function", " - powerpc/pseries/iommu: memory notifier incorrectly adds TCEs for pmemory", " - arch/powerpc/perf: Check the instruction type before creating sample", " with perf_mem_data_src", " - ip: fib_rules: Fetch net from fib_rule in fib[46]_rule_configure().", " - r8152: add vendor/device ID pair for Dell Alienware AW1022z", " - pstore: Change kmsg_bytes storage size to u32", " - ext4: don't write back data before punch hole in nojournal mode", " - ext4: remove writable userspace mappings before truncating page cache", " - wifi: rtw88: Fix download_firmware_validate() for RTL8814AU", " - wifi: rtw88: Fix __rtw_download_firmware() for RTL8814AU", " - clk: qcom: camcc-sm8250: Use clk_rcg2_shared_ops for some RCGs", " - hwmon: (xgene-hwmon) use appropriate type for the latency value", " - f2fs: introduce f2fs_base_attr for global sysfs entries", " - media: qcom: camss: csid: Only add TPG v4l2 ctrl if TPG hardware is", " available", " - ipv4: ip_gre: Fix set but not used warning in ipgre_err() if IPv4-only", " - r8169: don't scan PHY addresses > 0", " - bridge: mdb: Allow replace of a host-joined group", " - ice: treat dyn_allowed only as suggestion", " - rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y", " - rcu: handle unstable rdp in rcu_read_unlock_strict()", " - rcu: fix header guard for rcu_all_qs()", " - perf: Avoid the read if the count is already updated", " - ice: count combined queues using Rx/Tx count", " - net/mana: fix warning in the writer of client oob", " - scsi: lpfc: Handle duplicate D_IDs in ndlp search-by D_ID routine", " - scsi: lpfc: Free phba irq in lpfc_sli4_enable_msi() when", " pci_irq_vector() fails", " - scsi: st: Restore some drive settings after reset", " - wifi: ath12k: Avoid napi_sync() before napi_enable()", " - HID: usbkbd: Fix the bit shift number for LED_KANA", " - arm64: zynqmp: add clock-output-names property in clock nodes", " - ASoC: codecs: pcm3168a: Allow for 24-bit in provider mode", " - ASoC: rt722-sdca: Add some missing readable registers", " - drm/ast: Find VBIOS mode from regular display size", " - bpftool: Fix readlink usage in get_fd_type", " - firmware: arm_scmi: Relax duplicate name constraint across protocol ids", " - perf/amd/ibs: Fix perf_ibs_op.cnt_mask for CurCnt", " - perf/amd/ibs: Fix ->config to sample period calculation for OP PMU", " - wifi: rtl8xxxu: retry firmware download on error", " - wifi: rtw88: Don't use static local variable in", " rtw8822b_set_tx_power_index_by_rate", " - wifi: rtw89: add wiphy_lock() to work that isn't held wiphy_lock() yet", " - spi: zynqmp-gqspi: Always acknowledge interrupts", " - regulator: ad5398: Add device tree support", " - wifi: ath12k: fix ath12k_hal_tx_cmd_ext_desc_setup() info1 override", " - accel/qaic: Mask out SR-IOV PCI resources", " - wifi: ath9k: return by of_get_mac_address", " - wifi: ath12k: Fix end offset bit definition in monitor ring descriptor", " - drm: bridge: adv7511: fill stream capabilities", " - drm/atomic: clarify the rules around drm_atomic_state->allow_modeset", " - drm/panel-edp: Add Starry 116KHD024006", " - drm: Add valid clones check", " - ASoC: imx-card: Adjust over allocation of memory in imx_card_parse_of()", " - book3s64/radix: Fix compile errors when", " CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP=n", " - pinctrl: meson: define the pull up/down resistor value as 60 kOhm", " - ASoC: cs42l43: Disable headphone clamps during type detection", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Acer Aspire SW3-013", " - ALSA: hda/realtek: Add quirk for HP Spectre x360 15-df1xxx", " - nvme-pci: add quirks for device 126f:1001", " - nvme-pci: add quirks for WDC Blue SN550 15b7:5009", " - io_uring/fdinfo: annotate racy sq/cq head/tail reads", " - cifs: Fix and improve cifs_query_path_info() and cifs_query_file_info()", " - cifs: Fix changing times and read-only attr over SMB1", " smb_set_file_info() function", " - tools: ynl-gen: validate 0 len strings from kernel", " - wifi: iwlwifi: add support for Killer on MTL", " - xenbus: Allow PVH dom0 a non-local xenstore", " - soundwire: bus: Fix race on the creation of the IRQ domain", " - dmaengine: idxd: Fix allowing write() from different address spaces", " - kernel/fork: only call untrack_pfn_clear() on VMAs duplicated for fork()", " - remoteproc: qcom_wcnss: Fix on platforms without fallback regulators", " - clk: sunxi-ng: d1: Add missing divider for MMC mod clocks", " - xfrm: Sanitize marks before insert", " - dmaengine: idxd: Fix ->poll() return value", " - dmaengine: fsl-edma: Fix return code for unhandled interrupts", " - Bluetooth: L2CAP: Fix not checking l2cap_chan security level", " - Bluetooth: btusb: use skb_pull to avoid unsafe access in QCA dump", " handling", " - bridge: netfilter: Fix forwarding of fragmented packets", " - ice: fix vf->num_mac count with port representors", " - ice: Fix LACP bonds without SRIOV environment", " - pinctrl: qcom: switch to devm_register_sys_off_handler()", " - net: dwmac-sun8i: Use parsed internal PHY address instead of 1", " - net: lan743x: Restore SGMII CTRL register on resume", " - io_uring: fix overflow resched cqe reordering", " - octeontx2-pf: Add AF_XDP non-zero copy support", " - octeontx2-af: Set LMT_ENA bit for APR table entries", " - octeontx2-af: Fix APR entry mapping based on APR_LMT_CFG", " - clk: s2mps11: initialise clk_hw_onecell_data::num before accessing", " ::hws[] in probe()", " - can: slcan: allow reception of short error messages", " - ASoC: SOF: ipc4-control: Use SOF_CTRL_CMD_BINARY as numid for bytes_ext", " - ASoc: SOF: topology: connect DAI to a single DAI link", " - ASoC: SOF: ipc4-pcm: Delay reporting is only supported for playback", " direction", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14ASP10", " - llc: fix data loss when reading from a socket in llc_ui_recvmsg()", " - can: kvaser_pciefd: Continue parsing DMA buf after dropped RX", " - thermal: intel: x86_pkg_temp_thermal: Fix bogus trip temperature", " - drm/edid: fixed the bug that hdr metadata was not reset", " - arm64: dts: marvell: uDPU: define pinctrl state for alarm LEDs", " - smb: client: Reset all search buffer pointers when releasing buffer", " - Input: xpad - add more controllers", " - memcg: always call cond_resched() after fn()", " - mm/page_alloc.c: avoid infinite retries caused by cpuset race", " - Revert \"arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection\"", " - ksmbd: fix stream write failure", " - spi: spi-fsl-dspi: restrict register range for regmap access", " - spi: spi-fsl-dspi: Halt the module after a new message transfer", " - spi: spi-fsl-dspi: Reset SR flags before sending a new message", " - serial: sh-sci: Save and restore more registers", " - watchdog: aspeed: fix 64-bit division", " - pinctrl: tegra: Fix off by one in tegra_pinctrl_get_group()", " - i3c: master: svc: Fix implicit fallthrough in svc_i3c_master_ibi_work()", " - drm/gem: Internally test import_attach for imported objects", " - can: kvaser_pciefd: Force IRQ edge in case of nested IRQ", " - af_unix: Return struct unix_sock from unix_get_socket().", " - af_unix: Run GC on only one CPU.", " - af_unix: Try to run GC async.", " - af_unix: Replace BUG_ON() with WARN_ON_ONCE().", " - af_unix: Remove io_uring code for GC.", " - af_unix: Remove CONFIG_UNIX_SCM.", " - [Config] af_unix: remove UNIX_SCM config option", " - af_unix: Allocate struct unix_vertex for each inflight AF_UNIX fd.", " - af_unix: Allocate struct unix_edge for each inflight AF_UNIX fd.", " - af_unix: Link struct unix_edge when queuing skb.", " - af_unix: Bulk update unix_tot_inflight/unix_inflight when queuing skb.", " - af_unix: Iterate all vertices by DFS.", " - af_unix: Detect Strongly Connected Components.", " - af_unix: Save listener for embryo socket.", " - af_unix: Fix up unix_edge.successor for embryo socket.", " - af_unix: Save O(n) setup of Tarjan's algo.", " - af_unix: Skip GC if no cycle exists.", " - af_unix: Avoid Tarjan's algorithm if unnecessary.", " - af_unix: Assign a unique index to SCC.", " - af_unix: Detect dead SCC.", " - Revert \"UBUNTU: SAUCE: af_unix: Fix GC compatibility with upstream OOB", " refcount changes\"", " - af_unix: Replace garbage collection algorithm.", " - af_unix: Remove lock dance in unix_peek_fds().", " - af_unix: Try not to hold unix_gc_lock during accept().", " - af_unix: Don't access successor in unix_del_edges() during GC.", " - af_unix: Add dead flag to struct scm_fp_list.", " - af_unix: Fix garbage collection of embryos carrying OOB with SCM_RIGHTS", " - af_unix: Fix uninit-value in __unix_walk_scc()", " - SAUCE: Revert \"af_unix: Don't return OOB skb in manage_oob().\"", " - SAUCE: Revert \"af_unix: Move spin_lock() in manage_oob().\"", " - SAUCE: Revert \"af_unix: Rename unlinked_skb in manage_oob().\"", " - SAUCE: Revert \"af_unix: Remove single nest in manage_oob().\"", " - SAUCE: Revert \"af_unix: Don't call skb_get() for OOB skb.\"", " - af_unix: Define locking order for unix_table_double_lock().", " - af_unix: Define locking order for U_LOCK_SECOND in", " unix_state_double_lock().", " - af_unix: Define locking order for U_RECVQ_LOCK_EMBRYO in", " unix_collect_skb().", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Don't leave consecutive consumed OOB skbs.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - af_unix: Don't return OOB skb in manage_oob().", " - arm64: dts: qcom: ipq9574: Add missing properties for cryptobam", " - arm64: dts: qcom: sm8350: Fix typo in pil_camera_mem node", " - arm64: dts: qcom: sm8450: Add missing properties for cryptobam", " - arm64: dts: qcom: sm8550: Add missing properties for cryptobam", " - arm64: dts: ti: k3-am68-sk: Fix regulator hierarchy", " - perf/arm-cmn: Fix REQ2/SNP2 mixup", " - perf/arm-cmn: Initialise cmn->cpu earlier", " - coredump: fix error handling for replace_fd()", " - dmaengine: idxd: cdev: Fix uninitialized use of sva in idxd_cdev_open", " - HID: quirks: Add ADATA XPG alpha wireless mouse support", " - nfs: don't share pNFS DS connections between net namespaces", " - platform/x86: thinkpad_acpi: Support also NEC Lavie X1475JAS", " - um: let 'make clean' properly clean underlying SUBARCH as well", " - drm/amd/display: fix link_set_dpms_off multi-display MST corner case", " - phy: starfive: jh7110-usb: Fix USB 2.0 host occasional detection failure", " - spi: spi-sun4i: fix early activation", " - nvme-pci: add NVME_QUIRK_NO_DEEPEST_PS quirk for SOLIDIGM P44 Pro", " - NFS: Avoid flushing data while holding directory locks in nfs_rename()", " - platform/x86: fujitsu-laptop: Support Lifebook S2110 hotkeys", " - platform/x86: thinkpad_acpi: Ignore battery threshold change event", " notification", " - net: ethernet: ti: am65-cpsw: Lower random mac address error print to", " info", " - dma/mapping.c: dev_dbg support for dma_addressing_limited", " - mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf and rx_buf type", " - vhost_task: fix vhost_task_create() documentation", " - dma-mapping: Fix warning reported for missing prototype", " - fs/buffer: split locking for pagecache lookups", " - fs/buffer: introduce sleeping flavors for pagecache lookups", " - fs/buffer: use sleeping version of __find_get_block()", " - fs/ocfs2: use sleeping version of __find_get_block()", " - fs/jbd2: use sleeping version of __find_get_block()", " - fs/ext4: use sleeping version of sb_find_get_block()", " - drm/amd/display: Enable urgent latency adjustment on DCN35", " - iommufd: Extend IOMMU_GET_HW_INFO to report PASID capability", " - cifs: Set default Netbios RFC1001 server name to hostname in UNC", " - ASoC: codecs: wsa884x: Correct VI sense channel mask", " - ASoC: codecs: wsa883x: Correct VI sense channel mask", " - thermal/drivers/mediatek/lvts: Start sensor interrupts disabled", " - Bluetooth: btmtksdio: Prevent enabling interrupts after IRQ handler", " removal", " - drm/amdgpu/discovery: check ip_discovery fw file available", " - drm/amdkfd: set precise mem ops caps to disabled for gfx 11 and 12", " - xen/pci: Do not register devices with segments >= 0x10000", " - drm/amdgpu: Skip pcie_replay_count sysfs creation for VF", " - cgroup/rstat: avoid disabling irqs for O(num_cpu)", " - wifi: mt76: mt7996: fix SER reset trigger on WED reset", " - wifi: mt76: mt7925: load the appropriate CLC data based on hardware type", " - wifi: mt76: mt7925: fix fails to enter low power mode in suspend state", " - x86/headers: Replace __ASSEMBLY__ with __ASSEMBLER__ in UAPI headers", " - x86/cpu/intel: Replace PAT erratum model/family magic numbers with", " symbolic IFM references", " - x86/smpboot: Fix INIT delay assignment for extended Intel Families", " - x86/microcode/intel: Switch to new Intel CPU model defines", " - x86/microcode: Update the Intel processor flag scan check", " - blk-cgroup: improve policy registration error handling", " - drm/amdgpu: release xcp_mgr on exit", " - drm/amdgpu: adjust drm_firmware_drivers_only() handling", " - s390/tlb: Use mm_has_pgste() instead of mm_alloc_pgste()", " - clocksource/drivers/timer-riscv: Stop stimecmp when cpu hotplug", " - erofs: initialize decompression early", " - clk: qcom: lpassaudiocc-sc7280: Add support for LPASS resets for QCM6490", " - posix-timers: Ensure that timer initialization is fully visible", " - net: stmmac: dwmac-rk: Validate GRF and peripheral GRF during probe", " - net: hsr: Fix PRP duplicate detection", " - PNP: Expand length of fixup id string", " - arm64/mm: Check pmd_table() in pmd_trans_huge()", " - wifi: iwlwifi: mark Br device not integrated", " - wifi: mac80211: fix warning on disconnect during failed ML reconf", " - wifi: mac80211_hwsim: Fix MLD address translation", " - badblocks: Fix a nonsense WARN_ON() which checks whether a u64 variable", " < 0", " - coresight-etb10: change etb_drvdata spinlock's type to raw_spinlock_t", " - misc: pci_endpoint_test: Give disabled BARs a distinct error code", " - drm/amdkfd: Set per-process flags only once for gfx9/10/11/12", " - drm/xe: Retry BO allocation", " - soc: samsung: include linux/array_size.h where needed", " - usb: xhci: set page size to the xHCI-supported size", " - soc: mediatek: mtk-mutex: Add DPI1 SOF/EOF to MT8188 mutex tables", " - drm/amd/display: Ensure DMCUB idle before reset on DCN31/DCN35", " - drm/amd/display: Fix p-state type when p-state is unsupported", " - perf/core: Clean up perf_try_init_event()", " - net: phy: nxp-c45-tja11xx: add match_phy_device to TJA1103/TJA1104", " - dpll: Add an assertion to check freq_supported_num", " - ublk: enforce ublks_max only for unprivileged devices", " - scsi: logging: Fix scsi_logging_level bounds", " - ublk: complete command synchronously on error", " - drm/xe: xe_gen_wa_oob: replace program_invocation_short_name", " - bpf: Search and add kfuncs in struct_ops prologue and epilogue", " - drm/amd/display: fix dcn4x init failed", " - net/mlx5e: Add correct match to check IPSec syndromes for switchdev mode", " - scsi: mpi3mr: Update timestamp only for supervisor IOCs", " - scsi: scsi_debug: First fixes for tapes", " - net: ipv6: Init tunnel link-netns before registering dev", " - drm/amdgpu: remove all KFD fences from the BO on release", " - eeprom: ee1004: Check chip before probing", " - drm/amd/pm: Fetch current power limit from PMFW", " - drm/amd/display: DCN35 set min dispclk to 50Mhz", " - drm/amd/display: Fix DCN35 set min dispclk logic", " - drm/amd/display: Guard against setting dispclk low when active", " - drm/amd/display: Fix BT2020 YCbCr limited/full range input", " - drm/amd/display: Read LTTPR ALPM caps during link cap retrieval", " - hrtimers: Replace hrtimer_clock_to_base_table with switch-case", " - firmware: arm_ffa: Handle the presence of host partition in the", " partition info", " - firmware: xilinx: Dont send linux address to get fpga config get status", " - drm/xe: Stop ignoring errors from xe_ttm_stolen_mgr_init()", " - x86/ibt: Handle FineIBT in handle_cfi_failure()", " - soundwire: cadence_master: set frame shape and divider based on actual", " clk freq", " - net: stmmac: dwmac-loongson: Set correct {tx,rx}_fifo_size", " - drm/amdkfd: fix missing L2 cache info in topology", " - drm/amd/display: pass calculated dram_speed_mts to dml2", " - drm/amd/pm: Skip P2S load for SMU v13.0.12", " - drm/amd/display: Support multiple options during psr entry.", " - drm/amdgpu: Use active umc info from discovery", " - net/mlx5: XDP, Enable TX side XDP multi-buffer support", " - wifi: ath12k: fix the ampdu id fetch in the HAL_RX_MPDU_START TLV", " - wifi: iwlwifi: use correct IMR dump variable", " - wifi: mac80211: set ieee80211_prep_tx_info::link_id upon Auth Rx", " - powerpc/pseries/iommu: create DDW for devices with DMA mask less than", " 64-bits", " - wifi: rtw89: coex: Assign value over than 0 to avoid firmware timer hang", " - wifi: rtw89: fw: validate multi-firmware header before getting its size", " - wifi: rtw89: fw: validate multi-firmware header before accessing", " - wifi: rtw89: call power_on ahead before selecting firmware", " - net: page_pool: avoid false positive warning if NAPI was never added", " - media: qcom: camss: Add default case in vfe_src_pad_code", " - drm/rockchip: vop2: Improve display modes handling on RK3588 HDMI0", " - tools: ynl-gen: don't output external constants", " - ice: init flow director before RDMA", " - wifi: ath12k: Fetch regdb.bin file from board-2.bin", " - drm/nouveau: fix the broken marco GSP_MSG_MAX_SIZE", " - wifi: ath11k: Use dma_alloc_noncoherent for rx_tid buffer allocation", " - wifi: rtw89: coex: Separated Wi-Fi connecting event from Wi-Fi scan", " event", " - drm/xe/sa: Always call drm_suballoc_manager_fini()", " - drm/xe: Reject BO eviction if BO is bound to current VM", " - smb: server: smb2pdu: check return value of xa_store()", " - ACPI: platform-profile: add platform_profile_cycle()", " - platform/x86: ideapad-laptop: add support for some new buttons", " - ALSA: usb-audio: Fix duplicated name in MIDI substream names", " - btrfs: handle empty eb->folios in num_extent_folios()", " - xfrm: Fix UDP GRO handling for some corner cases", " - idpf: fix idpf_vport_splitq_napi_poll()", " - net: dsa: microchip: update tag_ksz masks for KSZ9477 family", " - net: dsa: microchip: linearize skb for tail-tagging switches", " - vmxnet3: update MTU after device quiesce", " - pmdomain: core: Fix error checking in genpd_dev_pm_attach_by_id()", " - highmem: add folio_test_partial_kmap()", " - mm: mmap: map MAP_STACK to VM_NOHUGEPAGE only if THP is enabled", " - nilfs2: fix deadlock warnings caused by lock dependency in init_nilfs()", " - Bluetooth: btmtksdio: Check function enabled before doing close", " - Bluetooth: btmtksdio: Do close if SDIO card removed without close", " - platform/x86: think-lmi: Fix attribute name usage for non-compliant", " items", " - err.h: move IOMEM_ERR_PTR() to err.h", " - gcc-15: make 'unterminated string initialization' just a warning", " - gcc-15: disable '-Wunterminated-string-initialization' entirely for now", " - Fix mis-uses of 'cc-option' for warning disablement", " - bpf: abort verification if env->cur_state->loop_entry != NULL", " - drm/amdkfd: Correct F8_MODE for gfx950", " - arm64: dts: qcom: sm8650: Add missing properties for cryptobam", " - arm64: dts: qcom: x1e80100-qcp: Fix vreg_l2j_1p2 voltage", " - arm64: dts: qcom: x1e80100-qcp: mark l12b and l15b always-on", " - arm64: dts: ti: k3-am62-main: Set eMMC clock parent to default", " - arm64: dts: ti: k3-am62p-j722s-common-main: Set eMMC clock parent to", " default", " - arm64: dts: ti: k3-am62x: Remove clock-names property from IMX219", " overlay", " - arm64: dts: ti: k3-am62x: Rename I2C switch to I2C mux in IMX219 overlay", " - arm64: dts: ti: k3-am62x: Rename I2C switch to I2C mux in OV5640 overlay", " - arm64: dts: ti: k3-am65-main: Fix sdhci node properties", " - arm64: dts: ti: k3-am65-main: Add missing taps to sdhci0", " - arm64: dts: ti: k3-j721e-sk: Model CSI2RX connector mux", " - arm64: dts: ti: k3-j721e-sk: Add support for multiple CAN instances", " - arm64: dts: ti: k3-j721e-sk: Add DT nodes for power regulators", " - drm/xe: Save the gt pointer in lrc and drop the tile", " - Upstream stable to v6.6.93, v6.12.31, v6.12.32", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38053", " - idpf: fix null-ptr-deref in idpf_features_check", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38055", " - perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38057", " - espintcp: fix skb leaks", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38060", " - bpf: copy_verifier_state() should copy 'loop_entry' field", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38098", " - drm/amd/display: Don't treat wb connector as physical in", " create_validate_stream_for_sink", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38099", " - Bluetooth: Disable SCO support if READ_VOICE_SETTING is", " unsupported/broken", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38073", " - block: fix race between set_blocksize and read paths", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38051", " - smb: client: Fix use-after-free in cifs_fill_dirent", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38077", " - platform/x86: dell-wmi-sysman: Avoid buffer overflow in", " current_password_store()", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38078", " - ALSA: pcm: Fix race of buffer access at PCM OSS layer", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38003", " - can: bcm: add missing rcu read protection for procfs content", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38004", " - can: bcm: add locking for bcm_op runtime updates", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38031", " - padata: do not leak refcount in reorder_work", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38079", " - crypto: algif_hash - fix double free in hash_accept", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38052", " - net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38097", " - espintcp: remove encap socket caching to avoid reference leak", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38058", " - __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38059", " - btrfs: avoid NULL pointer dereference if no valid csum tree", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38034", " - btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38035", " - nvmet-tcp: don't restore null sk_state_change", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38037", " - vxlan: Annotate FDB data races", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38039", " - net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload", " enabled", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38080", " - drm/amd/display: Increase block_sequence array size", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38040", " - serial: mctrl_gpio: split disable_ms into sync and no_sync APIs", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38061", " - net: pktgen: fix access outside of user given buffer in", " pktgen_thread_write()", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38062", " - genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of", " iommu_cookie", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38063", " - dm: fix unconditional IO throttle caused by REQ_PREFLUSH", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38043", " - firmware: arm_ffa: Set dma_mask for ffa devices", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38044", " - media: cx231xx: set device_caps for 417", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38065", " - orangefs: Do not truncate file size", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38066", " - dm cache: prevent BUG_ON by blocking retries on failed device resumes", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38068", " - crypto: lzo - Fix compression buffer overrun", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38045", " - wifi: iwlwifi: fix debug actions order", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38071", " - x86/mm: Check return value from memblock_phys_alloc_range()", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38072", " - libnvdimm/labels: Fix divide error in nd_label_data_init()", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38081", " - spi-rockchip: Fix register out of bounds access", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38074", " - vhost-scsi: protect vq->log_used with vq->mutex", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38048", " - virtio_ring: Fix data race by tagging event_triggered as racy for KCSAN", "", " * Noble update: upstream stable patchset 2025-11-28 (LP: #2133301) //", " CVE-2025-38075", " - scsi: target: iscsi: Fix timeout on deleted connection", "", " * CAP_PERFMON insufficient to get perf data (LP: #2131046)", " - SAUCE: perf/core: Allow CAP_PERFMON for paranoid level 4", "", " * Dell AIO backlight is not working, dell_uart_backlight module is missing", " (LP: #2083800)", " - SAUCE: Removed sauce dell-uart-backlight driver", " - Revert \"UBUNTU: SAUCE: ACPI: video: Dell AIO UART backlight detection\"", " - platform/x86: Add new Dell UART backlight driver", " - ACPI: video: Add Dell UART backlight controller detection", " - SAUCE: dell_uart_backlight: size_t -> ssize_t", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 7760 AIO", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - [Config] enable CONFIG_DELL_UART_BACKLIGHT", "", " * Ubuntu x86_64 6.8 kernels won't build if CONFIG_FB_HYPERV config option is", " enabled (LP: #2127971)", " - fbdev: Introduce devm_register_framebuffer()", "", " * Run iio_info will be stucked forever (HID-", " SENSOR-200011.5.auto/iio:device1) (LP: #2102077)", " - HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras", "", " * kernel: sysfs: cannot create duplicate filename", " '/bus/platform/devices/iTCO_wdt' (LP: #2121997)", " - i2c: i801: Hide Intel Birch Stream SoC TCO WDT", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344)", " - fs/xattr.c: fix simple_xattr_list to always include security.* xattrs", " - selftests/exec: load_address: conform test to TAP format output", " - binfmt_elf: Leave a gap between .bss and brk", " - selftests/exec: Build both static and non-static load_address tests", " - binfmt_elf: Calculate total_size earlier", " - binfmt_elf: Honor PT_LOAD alignment for static PIE", " - binfmt_elf: Move brk for static PIE even if ASLR disabled", " - platform/x86/amd/pmc: Declare quirk_spurious_8042 for MECHREVO Wujie", " 14XA (GX4HRXL)", " - platform/x86: asus-wmi: Fix wlan_ctrl_by_user detection", " - cgroup/cpuset: Extend kthread_is_per_cpu() check to all", " PF_NO_SETAFFINITY tasks", " - tracing: probes: Fix a possible race in trace_probe_log APIs", " - tpm: tis: Double the timeout B to 4s", " - firmware: arm_scmi: Add helper to trace bad messages", " - firmware: arm_scmi: Add message dump traces for bad and unexpected", " replies", " - firmware: arm_scmi: Add support for debug metrics at the interface", " - [Config] do not enable new support for SCMI debug metrics", " - firmware: arm_scmi: Track basic SCMI communication debug metrics", " - iio: adc: ad7266: Fix potential timestamp alignment issue.", " - iio: adc: ad7768-1: Fix insufficient alignment of timestamp.", " - iio: chemical: sps30: use aligned_s64 for timestamp", " - HID: thrustmaster: fix memory leak in thrustmaster_interrupts()", " - spi: loopback-test: Do not split 1024-byte hexdumps", " - Bluetooth: MGMT: Fix MGMT_OP_ADD_DEVICE invalid device flags", " - tools: ynl: ethtool.py: Output timestamping statistics from tsinfo-get", " operation", " - tools/net/ynl: ethtool: fix crash when Hardware Clock info is missing", " - mctp: no longer rely on net->dev_index_head[]", " - net: mctp: Ensure keys maintain only one ref to corresponding dev", " - ALSA: seq: Fix delivery of UMP events to group ports", " - ALSA: ump: Fix a typo of snd_ump_stream_msg_device_info", " - net: dsa: sja1105: discard incoming frames in BR_STATE_LISTENING", " - nvme-pci: make nvme_pci_npages_prp() __always_inline", " - nvme-pci: acquire cq_poll_lock in nvme_poll_irqdisable", " - ALSA: sh: SND_AICA should depend on SH_DMA_API", " - qlcnic: fix memory leak in qlcnic_sriov_channel_cfg_cmd()", " - octeontx2-pf: macsec: Fix incorrect max transmit size in TX secy", " - net: ethernet: mtk_eth_soc: fix typo for declaration MT7988 ESW", " capability", " - octeontx2-af: Fix CGX Receive counters", " - tsnep: fix timestamping with a stacked DSA driver", " - NFSv4/pnfs: Reset the layout state after a layoutreturn", " - udf: Make sure i_lenExtents is uptodate on inode eviction", " - LoongArch: Prevent cond_resched() occurring within kernel-fpu", " - LoongArch: Save and restore CSR.CNTC for hibernation", " - LoongArch: Fix MAX_REG_OFFSET calculation", " - LoongArch: uprobes: Remove user_{en,dis}able_single_step()", " - LoongArch: uprobes: Remove redundant code about resume_era", " - drm/amd/display: Correct the reply value when AUX write incomplete", " - drm/amd/display: Avoid flooding unnecessary info messages", " - ACPI: PPTT: Fix processor subtable walk", " - ALSA: es1968: Add error handling for snd_pcm_hw_constraint_pow2()", " - ALSA: usb-audio: Add sample rate quirk for Audioengine D1", " - ALSA: usb-audio: Add sample rate quirk for Microdia JP001 USB Camera", " - hv_netvsc: Use vmbus_sendpacket_mpb_desc() to send VMBus messages", " - hv_netvsc: Preserve contiguous PFN grouping in the page buffer array", " - hv_netvsc: Remove rmsg_pgcnt", " - Drivers: hv: Allow vmbus_sendpacket_mpb_desc() to create multiple ranges", " - Drivers: hv: vmbus: Remove vmbus_sendpacket_pagebuffer()", " - ftrace: Fix preemption accounting for stacktrace trigger command", " - ftrace: Fix preemption accounting for stacktrace filter command", " - tracing: samples: Initialize trace_array_printk() with the correct", " function", " - phy: Fix error handling in tegra_xusb_port_init", " - phy: renesas: rcar-gen3-usb2: Fix role detection on unbind/bind", " - phy: renesas: rcar-gen3-usb2: Set timing registers only once", " - scsi: sd_zbc: block: Respect bio vector limits for REPORT ZONES buffer", " - smb: client: fix memory leak during error handling for POSIX mkdir", " - spi: tegra114: Use value to check for invalid delays", " - net: qede: Initialize qede_ll_ops with designated initializer", " - dmaengine: ti: k3-udma: Use cap_mask directly from dma_device structure", " instead of a local copy", " - dmaengine: idxd: fix memory leak in error handling path of", " idxd_setup_wqs", " - dmaengine: idxd: fix memory leak in error handling path of", " idxd_setup_engines", " - dmaengine: idxd: fix memory leak in error handling path of", " idxd_setup_groups", " - dmaengine: idxd: Add missing cleanup for early error out in", " idxd_setup_internals", " - dmaengine: idxd: Add missing cleanups in cleanup internals", " - dmaengine: idxd: Add missing idxd cleanup to fix memory leak in remove", " call", " - dmaengine: idxd: fix memory leak in error handling path of", " idxd_pci_probe", " - LoongArch: Explicitly specify code model in Makefile", " - SAUCE: Revert \"memblock: Accept allocated memory before use in", " memblock_double_array()\"", " - phy: tegra: xusb: remove a stray unlock", " - drivers/platform/x86/amd: pmf: Check for invalid sideloaded Smart PC", " Policies", " - drivers/platform/x86/amd: pmf: Check for invalid Smart PC Policies", " - uio_hv_generic: Fix sysfs creation path for ring buffer", " - KVM: Add member to struct kvm_gfn_range to indicate private/shared", " - KVM: x86/mmu: Prevent installing hugepages when mem attributes are", " changing", " - iio: chemical: pms7003: use aligned_s64 for timestamp", " - iio: pressure: mprls0025pa: use aligned_s64 for timestamp", " - net: dsa: b53: prevent standalone from trying to forward to other ports", " - netlink: specs: tc: fix a couple of attribute names", " - LoongArch: Move __arch_cpu_idle() to .cpuidle.text section", " - btrfs: fix discard worker infinite loop after disabling discard", " - btrfs: fix folio leak in submit_one_async_extent()", " - btrfs: add back warning for mount option commit values exceeding 300", " - drm/amdgpu: fix incorrect MALL size for GFX1151", " - gpio: pca953x: fix IRQ storm on system wake up", " - kbuild: Disable -Wdefault-const-init-unsafe", " - mm: userfaultfd: correct dirty flags set for both present and swap pte", " - accel/ivpu: Rename ivpu_log_level to fw_log_level", " - accel/ivpu: Reset fw log on cold boot", " - accel/ivpu: Refactor functions in ivpu_fw_log.c", " - drm/fbdev-dma: Support struct drm_driver.fbdev_probe", " - Upstream stable to v6.6.92, v6.12.30", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-37968", " - iio: light: opt3001: fix deadlock due to concurrent flag access", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38011", " - drm/amdgpu: csa unmap use uninterruptible lock", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-21931", " - hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-37960", " - memblock: Accept allocated memory before use in memblock_double_array()", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-37967", " - usb: typec: ucsi: displayport: Fix deadlock", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-22102", " - Bluetooth: btnxpuart: Fix kernel panic during FW release", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38008", " - mm/page_alloc: fix race condition in unaccepted memory handling", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38014", " - dmaengine: idxd: Refactor remove call with idxd_cleanup() helper", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38015", " - dmaengine: idxd: fix memory leak in error handling path of idxd_alloc", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38005", " - dmaengine: ti: k3-udma: Add missing locking", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38009", " - wifi: mt76: disable napi on driver removal", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38010", " - phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38095", " - dma-buf: insert memory barrier before updating num_fences", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38018", " - net/tls: fix kernel panic when alloc_page failed", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38019", " - mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38013", " - wifi: mac80211: Set n_channels after allocating struct", " cfg80211_scan_request", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38027", " - regulator: max20086: fix invalid memory access", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38020", " - net/mlx5e: Disable MACsec offload for uplink representor profile", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38094", " - net: cadence: macb: Fix a possible deadlock in macb_halt_tx.", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38006", " - net: mctp: Don't access ifa_index when missing", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-37992", " - net_sched: Flush gso_skb list too during ->change()", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38023", " - nfs: handle failure of nfs_get_lock_context in unlock path", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38007", " - HID: uclogic: Add NULL check in uclogic_input_configured()", "", " * Noble update: upstream stable patchset 2025-10-30 (LP: #2130344) //", " CVE-2025-38024", " - RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277)", " - dm: add missing unlock on in dm_keyslot_evict()", " - arm64: dts: imx8mm-verdin: Link reg_usdhc2_vqmmc to usdhc2", " - can: mcan: m_can_class_unregister(): fix order of unregistration calls", " - can: mcp251xfd: mcp251xfd_remove(): fix order of unregistration calls", " - ksmbd: fix memory leak in parse_lease_state()", " - SAUCE: Revert \"sch_htb: make htb_deactivate() idempotent\"", " - sch_htb: make htb_deactivate() idempotent", " - gre: Fix again IPv6 link-local address generation.", " - netdevice: add netdev_tx_reset_subqueue() shorthand", " - net: ethernet: mtk_eth_soc: reset all TX queues on DMA free", " - can: mcp251xfd: fix TDC setting for low data bit rates", " - can: gw: fix RCU/BH usage in cgw_create_job()", " - net: dsa: b53: allow leaky reserved multicast", " - net: dsa: b53: fix clearing PVID of a port", " - net: dsa: b53: fix flushing old pvid VLAN on pvid change", " - net: dsa: b53: fix VLAN ID for untagged vlan on bridge leave", " - net: dsa: b53: always rejoin default untagged VLAN on bridge leave", " - net: dsa: b53: fix learning on VLAN unaware bridges", " - Input: cyttsp5 - ensure minimum reset pulse width", " - Input: cyttsp5 - fix power control issue on wakeup", " - Input: xpad - fix Share button on Xbox One controllers", " - Input: xpad - add support for 8BitDo Ultimate 2 Wireless Controller", " - Input: synaptics - enable InterTouch on Dynabook Portege X30-D", " - Input: synaptics - enable InterTouch on Dynabook Portege X30L-G", " - Input: synaptics - enable InterTouch on Dell Precision M3800", " - Input: synaptics - enable SMBus for HP Elitebook 850 G1", " - Input: synaptics - enable InterTouch on TUXEDO InfinityBook Pro 14 v5", " - staging: iio: adc: ad7816: Correct conditional logic for store mode", " - staging: axis-fifo: Remove hardware resets for user errors", " - staging: axis-fifo: Correct handling of tx_fifo_depth for size", " validation", " - drm/amd/display: Shift DMUB AUX reply command if necessary", " - iio: adc: ad7606: fix serial register access", " - iio: adc: rockchip: Fix clock initialization sequence", " - iio: adis16201: Correct inclinometer channel resolution", " - drm/amd/display: Fix the checking condition in dmub aux handling", " - drm/amd/display: Remove incorrect checking in dmub aux handler", " - drm/amd/display: Fix wrong handling for AUX_DEFER case", " - drm/amd/display: Copy AUX read reply data whenever length > 0", " - usb: uhci-platform: Make the clock really optional", " - xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it", " - clocksource/i8253: Use raw_spinlock_irqsave() in", " clockevent_i8253_disable()", " - x86/microcode: Consolidate the loader enablement checking", " - ocfs2: switch osb->disable_recovery to enum", " - ocfs2: implement handshaking with ocfs2 recovery thread", " - ocfs2: stop quota recovery before disabling quotas", " - usb: cdnsp: Fix issue with resuming from L1", " - usb: cdnsp: fix L1 resume issue for RTL_REVISION_NEW_LPM version", " - usb: gadget: f_ecm: Add get_status callback", " - usb: gadget: tegra-xudc: ACK ST_RC after clearing CTRL_RUN", " - usb: gadget: Use get_status callback to set remote wakeup capability", " - usb: host: tegra: Prevent host controller crash when OTG port is used", " - usb: typec: tcpm: delay SNK_TRY_WAIT_DEBOUNCE to SRC_TRYWAIT transition", " - USB: usbtmc: use interruptible sleep in usbtmc_read", " - usb: usbtmc: Fix erroneous get_stb ioctl error returns", " - usb: usbtmc: Fix erroneous wait_srq ioctl return", " - usb: usbtmc: Fix erroneous generic_read ioctl return", " - iio: accel: adxl367: fix setting odr for activity time update", " - iio: temp: maxim-thermocouple: Fix potential lack of DMA safe buffer.", " - types: Complement the aligned types with signed 64-bit one", " - iio: accel: adxl355: Make timestamp 64-bit aligned using aligned_s64", " - iio: adc: dln2: Use aligned_s64 for timestamp", " - MIPS: Fix MAX_REG_OFFSET", " - drm/panel: simple: Update timings for AUO G101EVN010", " - do_umount(): add missing barrier before refcount checks in sync case", " - io_uring: always arm linked timeouts prior to issue", " - arm64: insn: Add support for encoding DSB", " - arm64: proton-pack: Expose whether the platform is mitigated by firmware", " - arm64: proton-pack: Expose whether the branchy loop k value", " - arm64: proton-pack: Add new CPUs 'k' values for branch mitigation", " - x86/bpf: Call branch history clearing sequence on exit", " - x86/bpf: Add IBHF call at end of classic BPF", " - x86/bhi: Do not set BHI_DIS_S in 32-bit mode", " - x86/speculation: Simplify and make CALL_NOSPEC consistent", " - x86/speculation: Add a conditional CS prefix to CALL_NOSPEC", " - x86/speculation: Remove the extra #ifdef around CALL_NOSPEC", " - Documentation: x86/bugs/its: Add ITS documentation", " - x86/its: Enumerate Indirect Target Selection (ITS) bug", " - x86/its: Add support for ITS-safe indirect thunk", " - [Config] enable Indirect Target Selection mitigation", " - x86/its: Add support for ITS-safe return thunk", " - x86/its: Enable Indirect Target Selection mitigation", " - x86/its: Add \"vmexit\" option to skip mitigation on some CPUs", " - x86/its: Add support for RSB stuffing mitigation", " - x86/its: Align RETs in BHB clear sequence to avoid thunking", " - x86/ibt: Keep IBT disabled during alternative patching", " - x86/its: Use dynamic thunks for indirect branches", " - x86/its: Fix build errors when CONFIG_MODULES=n", " - x86/its: FineIBT-paranoid vs ITS", " - x86/its: Fix build error for its_static_thunk()", " - firmware: arm_scmi: Fix timeout checks on polling path", " - s390/entry: Fix last breaking event handling in case of stack corruption", " - erofs: ensure the extra temporary copy is valid for shortened bvecs", " - net: dsa: b53: keep CPU port always tagged again", " - net: dsa: b53: do not allow to configure VLAN 0", " - net: dsa: b53: do not program vlans when vlan filtering is off", " - net: dsa: b53: fix toggling vlan_filtering", " - net: dsa: b53: do not set learning and unicast/multicast on up", " - rust: clean Rust 1.88.0's warning about `clippy::disallowed_macros`", " configuration", " - mm/userfaultfd: fix uninitialized output field for -EAGAIN race", " - selftests/mm: compaction_test: support platform with huge mount of", " memory", " - selftests/mm: fix a build failure on powerpc", " - io_uring: ensure deferred completions are flushed for multishot", " - iio: imu: inv_mpu6050: align buffer for timestamp", " - drm/xe: Add page queue multiplier", " - usb: dwc3: gadget: Make gadget_wakeup asynchronous", " - riscv: misaligned: Add handling for ZCB instructions", " - riscv: misaligned: factorize trap handling", " - riscv: misaligned: enable IRQs while handling misaligned accesses", " - selftest/x86/bugs: Add selftests for ITS", " - Upstream stable to v6.6.91, v6.12.29", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37960", " - memblock: Accept allocated memory before use in memblock_double_array()", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37957", " - KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37963", " - arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37948", " - arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37994", " - usb: typec: ucsi: displayport: Fix NULL pointer access", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37995", " - module: ensure that kobject_put() is safe for module type kobjects", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37949", " - xenbus: Use kref to track req lifetime", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37954", " - smb: client: Avoid race in open_cached_dir with lease breaks", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37951", " - drm/v3d: Add job to pending list if the reset was skipped", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37969", " - iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37970", " - iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37972", " - Input: mtk-pmic-keys - fix possible null pointer dereference", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37959", " - bpf: Scrub packet on bpf_redirect_peer", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37961", " - ipvs: fix uninit-value for saddr in do_output_route4", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37998", " - openvswitch: Fix unsafe attribute parsing in output_userspace()", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37952", " - ksmbd: Fix UAF in __close_file_table_ids", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37947", " - ksmbd: prevent out-of-bounds stream writes by validating *pos", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37956", " - ksmbd: prevent rename with empty string", "", " * Noble update: upstream stable patchset 2025-10-29 (LP: #2130277) //", " CVE-2025-37973", " - wifi: cfg80211: fix out-of-bounds access during multi-link element", " defragmentation", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559)", " - ALSA: usb-audio: Add retry on -EPROTO from usb_set_interface()", " - ALSA: usb-audio: Add second USB ID for Jabra Evolve 65 headset", " - btrfs: fix COW handling in run_delalloc_nocow()", " - drm/fdinfo: Protect against driver unbind", " - EDAC/altera: Test the correct error reg offset", " - EDAC/altera: Set DDR and SDMMC interrupt mask before registration", " - i2c: imx-lpi2c: Fix clock count when probe defers", " - arm64: errata: Add missing sentinels to Spectre-BHB MIDR arrays", " - amd-xgbe: Fix to ensure dependent features are toggled with RX checksum", " offload", " - mm/memblock: pass size instead of end to memblock_set_node()", " - mm/memblock: repeat setting reserved region nid if array is doubled", " - mmc: renesas_sdhi: Fix error handling in renesas_sdhi_probe", " - spi: tegra114: Don't fail set_cs_timing when delays are zero", " - tracing: Do not take trace_event_sem in print_event_fields()", " - dm-integrity: fix a warning on invalid table line", " - dm: always update the array size in realloc_argv on success", " - iommu/vt-d: Apply quirk_iommu_igfx for 8086:0044 (QM57/QS57)", " - platform/x86/amd: pmc: Require at least 2.5 seconds between HW sleep", " cycles", " - platform/x86/intel-uncore-freq: Fix missing uncore sysfs during CPU", " hotplug", " - smb: client: fix zero length for mkdir POSIX create context", " - cpufreq: Avoid using inconsistent policy->min and policy->max", " - cpufreq: Fix setting policy limits when frequency tables are used", " - PCI: imx6: Skip controller_id generation logic for i.MX7D", " - ASoC: soc-pcm: Fix hw_params() and DAPM widget sequence", " - powerpc/boot: Check for ld-option support", " - drm/i915/pxp: fix undefined reference to", " `intel_pxp_gsccs_is_ready_for_sessions'", " - powerpc/boot: Fix dash warning", " - net/mlx5: E-Switch, Initialize MAC Address for Default GID", " - net/mlx5: E-switch, Fix error handling for enabling roce", " - net: Rename mono_delivery_time to tstamp_type for scalabilty", " - Bluetooth: L2CAP: copy RX timestamp to new fragments", " - net: mscc: ocelot: treat 802.1ad tagged traffic as 802.1Q-untagged", " - net: mscc: ocelot: delete PVID VLAN when readding it as non-PVID", " - net: ethernet: mtk-star-emac: rearm interrupts in rx_poll only when", " advised", " - pds_core: delete VF dev on reset", " - pds_core: make pdsc_auxbus_dev_del() void", " - pds_core: specify auxiliary_device to be created", " - nvme-pci: fix queue unquiesce check on slot_reset", " - net: dlink: Correct endianness handling of led_mode", " - net: mdio: mux-meson-gxl: set reversed bit when using internal phy", " - igc: fix lock order in igc_ptp_reset", " - net: dsa: felix: fix broken taprio gate states after clock jump", " - net: ipv6: fix UDPv6 GSO segmentation with NAT", " - bnxt_en: Fix coredump logic to free allocated buffer", " - bnxt_en: Fix ethtool -d byte order for 32-bit values", " - nvme-tcp: fix premature queue removal and I/O failover", " - net: fec: ERR007885 Workaround for conventional TX", " - net: hns3: store rx VLAN tag offload state for VF", " - net: hns3: fix an interrupt residual problem", " - net: hns3: fixed debugfs tm_qset size", " - net: hns3: defer calling ptp_clock_register()", " - net: vertexcom: mse102x: Fix possible stuck of SPI interrupt", " - net: vertexcom: mse102x: Fix LEN_MASK", " - net: vertexcom: mse102x: Add range check for CMD_RTS", " - net: vertexcom: mse102x: Fix RX error handling", " - ASoC: Use of_property_read_bool()", " - ASoC: soc-core: Stop using of_property_read_bool() for non-boolean", " properties", " - firmware: arm_ffa: Skip Rx buffer ownership release if not acquired", " - ARM: dts: opos6ul: add ksz8081 phy properties", " - arm64: dts: st: Adjust interrupt-controller for stm32mp25 SoCs", " - arm64: dts: st: Use 128kB size for aliased GIC400 register access on", " stm32mp25 SoCs", " - Revert \"drm/meson: vclk: fix calculation of 59.94 fractional rates\"", " - xhci: Add helper to set an interrupters interrupt moderation interval", " - xhci: support setting interrupt moderation IMOD for secondary", " interrupters", " - xhci: Limit time spent with xHC interrupts disabled during bus resume", " - kernel: param: rename locate_module_kobject", " - kernel: globalize lookup_or_create_module_kobject()", " - drivers: base: handle module_kobject creation", " - iommu/arm-smmu-v3: Use the new rb tree helpers", " - iommu/arm-smmu-v3: Fix iommu_device_probe bug due to duplicated stream", " ids", " - drm/amd/display: Add scoped mutexes for amdgpu_dm_dhcp", " - dm: fix copying after src array boundaries", " - bpf: Fix BPF_INTERNAL namespace import", " - binder: fix offset calculation in debug log", " - perf/x86/intel: Only check the group flag for X86 leader", " - drm: Select DRM_KMS_HELPER from DRM_DEBUG_DP_MST_TOPOLOGY_REFS", " - iommu/arm-smmu-v3: Fix pgsize_bit for sva domains", " - pinctrl: imx: Return NULL if no group is matched and found", " - Bluetooth: hci_conn: Fix not setting timeout for BIG Create Sync", " - idpf: fix offloads support for encapsulated packets", " - drm/tests: shmem: Fix memleak", " - idpf: fix potential memory leak on kcalloc() failure", " - idpf: protect shutdown from reset", " - ALSA: hda/realtek: Fix built-mic regression on other ASUS models", " - bnxt_en: Add missing skb_mark_for_recycle() in bnxt_rx_vlan()", " - nvme-tcp: select CONFIG_TLS from CONFIG_NVME_TCP_TLS", " - nvmet-tcp: select CONFIG_TLS from CONFIG_NVME_TARGET_TCP_TLS", " - accel/ivpu: Fix a typo", " - drm/xe: Ensure fixed_slice_mode gets set after ccs_mode change", " - Upstream stable to v6.6.90, v6.12.27, v6.12.28", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37920", " - xsk: Fix race condition in AF_XDP generic RX path", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37900", " - iommu: Fix two issues in iommu_copy_struct_from_user()", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37931", " - btrfs: adjust subpage bit start based on sectorsize", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37903", " - drm/amd/display: Fix slab-use-after-free in hdcp", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37905", " - firmware: arm_scmi: Balance device refcount when destroying devices", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37933", " - octeon_ep: Fix host hang issue during device reboot", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37909", " - net: lan743x: Fix memleak issue when GSO enabled", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37911", " - bnxt_en: Fix out-of-bound memcpy() during ethtool -w", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37935", " - net: ethernet: mtk_eth_soc: fix SER panic with 4GB+ RAM", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37891", " - ALSA: ump: Fix buffer overflow at UMP SysEx message conversion", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37912", " - ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37913", " - net_sched: qfq: Fix double list add in class with netem as child qdisc", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37914", " - net_sched: ets: Fix double list add in class with netem as child qdisc", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37915", " - net_sched: drr: Fix double list add in class with netem as child qdisc", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37916", " - pds_core: remove write-after-free of client_id", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37917", " - net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx", " poll", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37918", " - Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37921", " - vxlan: vnifilter: Fix unlocked deletion of default FDB entry", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37897", " - wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37922", " - book3s64/radix : Align section vmemmap start address to PAGE_SIZE", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37923", " - tracing: Fix oob write in trace_seq_to_buffer()", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37924", " - ksmbd: fix use-after-free in kerberos authentication", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37927", " - iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37928", " - dm-bufio: don't schedule in atomic context", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37990", " - wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37901", " - irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37936", " - perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's", " value.", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37991", " - parisc: Fix double SIGFPE crash", "", " * Noble update: upstream stable patchset 2025-10-22 (LP: #2129559) //", " CVE-2025-37930", " - drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307)", " - module: sign with sha512 instead of sha1 by default", " - x86/extable: Remove unused fixup type EX_TYPE_COPY", " - tracing: Add __string_len() example", " - tracing: Add __print_dynamic_array() helper", " - soc: qcom: ice: introduce devm_of_qcom_ice_get", " - mmc: sdhci-msm: fix dev reference leaked through of_qcom_ice_get", " - auxdisplay: hd44780: Convert to platform remove callback returning void", " - auxdisplay: hd44780: Fix an API misuse in hd44780.c", " - net: dsa: mv88e6xxx: fix internal PHYs for 6320 family", " - net: dsa: mv88e6xxx: fix VTU methods for 6320 family", " - ASoC: qcom: q6apm-dai: drop unused 'q6apm_dai_rtd' fields", " - ASoC: q6apm-dai: schedule all available frames to avoid dsp under-runs", " - ASoC: q6apm-dai: make use of q6apm_get_hw_pointer", " - iio: adc: ad7768-1: Move setting of val a bit later to avoid unnecessary", " return value check", " - iio: adc: ad7768-1: Fix conversion result sign", " - arm64: tegra: Remove the Orin NX/Nano suspend key", " - clk: renesas: r9a07g04[34]: Fix typo for sel_shdi variable", " - clk: renesas: r9a07g043: Fix HP clock source for RZ/Five", " - of: resolver: Simplify of_resolve_phandles() using __free()", " - of: resolver: Fix device node refcount leakage in of_resolve_phandles()", " - scsi: ufs: qcom: fix dev reference leaked through of_qcom_ice_get", " - cpufreq/sched: Explicitly synchronize limits_changed flag handling", " - ceph: Fix incorrect flush end position calculation", " - dma/contiguous: avoid warning about unused size_bytes", " - cpufreq: cppc: Fix invalid return value in .get() callback", " - btrfs: avoid page_lockend underflow in btrfs_punch_hole_lock_range()", " - scsi: core: Clear flags for scsi_cmnd that did not complete", " - net: ethernet: mtk_eth_soc: net: revise NETSYSv3 hardware configuration", " - net: dsa: mt7530: sync driver-specific behavior of MT7531 variants", " - pds_core: Remove unnecessary check in pds_client_adminq_cmd()", " - iommu/amd: Return an error if vCPU affinity is set for non-vCPU IRTE", " - splice: remove duplicate noinline from pipe_clear_nowait", " - perf/x86: Fix non-sampling (counting) events on certain x86 platforms", " - LoongArch: Select ARCH_USE_MEMTEST", " - LoongArch: Make regs_irqs_disabled() more clear", " - LoongArch: Make do_xyz() exception handlers more robust", " - virtio_console: fix missing byte order handling for cols and rows", " - crypto: atmel-sha204a - Set hwrng quality to lowest possible", " - net: selftests: initialize TCP header and skb payload with zero", " - net: phy: microchip: force IRQ polling mode for lan88xx", " - drm/amd/display: Fix gpu reset in multidisplay config", " - LoongArch: Return NULL from huge_pte_offset() for invalid PMD", " - LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()", " - LoongArch: Remove a bogus reference to ZONE_DMA", " - io_uring: fix 'sync' handling of io_fallback_tw()", " - KVM: SVM: Allocate IR data using atomic allocation", " - cxl/core/regs.c: Skip Memory Space Enable check for RCD and RCH Ports", " - ata: libata-scsi: Improve CDL control", " - ata: libata-scsi: Fix ata_mselect_control_ata_feature() return type", " - ata: libata-scsi: Fix ata_msense_control_ata_feature()", " - USB: storage: quirk for ADATA Portable HDD CH94", " - scsi: Improve CDL control", " - mei: me: add panther lake H DID", " - KVM: x86: Explicitly treat routing entry type changes as changes", " - char: misc: register chrdev region with all possible minors", " - misc: microchip: pci1xxxx: Fix incorrect IRQ status handling during ack", " - serial: msm: Configure correct working mode before starting earlycon", " - serial: sifive: lock port in startup()/shutdown() callbacks", " - USB: serial: ftdi_sio: add support for Abacus Electrics Optical Probe", " - USB: serial: option: add Sierra Wireless EM9291", " - USB: serial: simple: add OWON HDS200 series oscilloscope support", " - usb: chipidea: ci_hdrc_imx: fix call balance of regulator routines", " - usb: chipidea: ci_hdrc_imx: implement usb_phy_init() error handling", " - USB: OHCI: Add quirk for LS7A OHCI controller (rev 0x02)", " - usb: dwc3: xilinx: Prevent spike in reset signal", " - usb: quirks: add DELAY_INIT quirk for Silicon Motion Flash Drive", " - usb: quirks: Add delay init quirk for SanDisk 3.2Gen1 Flash Drive", " - USB: VLI disk crashes if LPM is used", " - USB: wdm: handle IO errors in wdm_wwan_port_start", " - USB: wdm: wdm_wwan_port_tx_complete mutex in atomic context", " - USB: wdm: add annotation", " - pinctrl: renesas: rza2: Fix potential NULL pointer dereference", " - MIPS: cm: Detect CM quirks from device tree", " - crypto: ccp - Add support for PCI device 0x1134", " - clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec()", " - parisc: PDT: Fix missing prototype warning", " - s390/tty: Fix a potential memory leak bug", " - bpf: bpftool: Setting error code in do_loader()", " - bpf: Only fails the busy counter check in bpf_cgrp_storage_get if it", " creates storage", " - bpf: Reject attaching fexit/fmod_ret to __noreturn functions", " - mailbox: pcc: Fix the possible race in updation of chan_in_use flag", " - mailbox: pcc: Always clear the platform ack interrupt first", " - usb: host: max3421-hcd: Add missing spi_device_id table", " - fs/ntfs3: Fix WARNING in ntfs_extend_initialized_size", " - usb: dwc3: gadget: Refactor loop to avoid NULL endpoints", " - usb: dwc3: gadget: Avoid using reserved endpoints on Intel Merrifield", " - usb: host: xhci-plat: mvebu: use ->quirks instead of ->init_quirk() func", " - thunderbolt: Scan retimers after device router has been enumerated", " - objtool: Silence more KCOV warnings", " - objtool, panic: Disable SMAP in __stack_chk_fail()", " - objtool, ASoC: codecs: wcd934x: Remove potential undefined behavior in", " wcd934x_slim_irq_handler()", " - objtool, regulator: rk808: Remove potential undefined behavior in", " rk806_set_mode_dcdc()", " - objtool, lkdtm: Obfuscate the do_nothing() pointer", " - ntb: reduce stack usage in idt_scan_mws", " - ntb_hw_amd: Add NTB PCI ID for new gen CPU", " - rtc: pcf85063: do a SW reset if POR failed", " - io_uring: always do atomic put from iowq", " - sched/isolation: Make CONFIG_CPU_ISOLATION depend on CONFIG_SMP", " - KVM: s390: Don't use %pK through tracepoints", " - KVM: s390: Don't use %pK through debug printing", " - selftests: ublk: fix test_stripe_04", " - xen: Change xen-acpi-processor dom0 dependency", " - ACPI: EC: Set ec_no_wakeup for Lenovo Go S", " - ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls", " - nvme: multipath: fix return value of nvme_available_path", " - objtool: Stop UNRET validation on UD2", " - gpiolib: of: Move Atmel HSMCI quirk up out of the regulator comment", " - selftests/mincore: Allow read-ahead pages to reach the end of the file", " - x86/bugs: Use SBPB in write_ibpb() if applicable", " - x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline", " - x86/bugs: Don't fill RSB on context switch with eIBRS", " - nvmet-fc: take tgtport reference only once", " - cifs: Fix encoding of SMB1 Session Setup Kerberos Request in non-UNICODE", " mode", " - timekeeping: Add a lockdep override in tick_freeze()", " - ext4: make block validity check resistent to sb bh corruption", " - scsi: hisi_sas: Fix I/O errors caused by hardware port ID changes", " - scsi: ufs: exynos: Ensure pre_link() executes before", " exynos_ufs_phy_init()", " - scsi: pm80xx: Set phy_attached to zero when device is gone", " - x86/i8253: Call clockevent_i8253_disable() with interrupts disabled", " - iomap: skip unnecessary ifs_block_is_uptodate check", " - riscv: Provide all alternative macros all the time", " - loop: aio inherit the ioprio of original request", " - spi: tegra210-quad: use WARN_ON_ONCE instead of WARN_ON for timeouts", " - spi: tegra210-quad: add rate limiting and simplify timeout error message", " - ubsan: Fix panic from test_ubsan_out_of_bounds", " - x86/cpu: Add CPU model number for Bartlett Lake CPUs with Raptor Cove", " cores", " - x86/pvh: Call C code via the kernel virtual mapping", " - Revert \"drivers: core: synchronize really_probe() and dev_uevent()\"", " - driver core: introduce device_set_driver() helper", " - comedi: jr3_pci: Fix synchronous deletion of timer", " - net: dsa: mv88e6xxx: fix atu_move_port_mask for 6341 family", " - net: dsa: mv88e6xxx: enable PVT for 6321 switch", " - net: dsa: mv88e6xxx: enable .port_set_policy() for 6320 family", " - net: dsa: mv88e6xxx: enable STU methods for 6320 family", " - MIPS: cm: Fix warning if MIPS_CM is disabled", " - objtool: Ignore end-of-section jumps for KCOV/GCOV", " - objtool: Silence more KCOV warnings, part 2", " - ALSA: hda/cirrus_scodec_test: Don't select dependencies", " - ALSA: hda: improve bass speaker support for ASUS Zenbook UM5606WA", " - ALSA: hda/realtek: Workaround for resume on Dell Venue 11 Pro 7130", " - ALSA: hda/realtek - Fixed ASUS platform headset Mic issue", " - net: ethernet: mtk_eth_soc: reapply mdc divider on reset", " - riscv: Use kvmalloc_array on relocation_hashtable", " - riscv: module: Allocate PLT entries for R_RISCV_PLT32", " - ASoC: fsl: fsl_qmc_audio: Reset audio data pointers on TRIGGER_START", " event", " - dma-buf/sw_sync: Decrement refcount on error in", " sw_sync_ioctl_get_deadline()", " - mm/compaction: fix bug in hugetlb handling pathway", " - platform/x86: amd: pmf: Fix STT limits", " - drm/amd/display: Add HP Elitebook 645 to the quirk list for eDP on DP1", " - drm/amd/display: Add HP Probook 445 and 465 to the quirk list for eDP on", " DP1", " - drm/xe/dma_buf: stop relying on placement in unmap", " - drm/amdgpu: fix warning of drm_mm_clean", " - arm64/sysreg: Update register fields for ID_AA64MMFR0_EL1", " - arm64/sysreg: Add register fields for HDFGRTR2_EL2", " - arm64/sysreg: Add register fields for HDFGWTR2_EL2", " - arm64/sysreg: Add register fields for HFGITR2_EL2", " - arm64/sysreg: Add register fields for HFGRTR2_EL2", " - arm64/sysreg: Add register fields for HFGWTR2_EL2", " - kbuild: Add '-fno-builtin-wcslen'", " - drm/amd/display: Temporarily disable hostvm on DCN31", " - block: remove rq_list_move", " - bpf: add find_containing_subprog() utility function", " - selftests/bpf: test for changing packet data from global functions", " - selftests/bpf: freplace tests for tracking of changes_packet_data", " - selftests/bpf: validate that tail call invalidates packet pointers", " - selftests/bpf: extend changes_pkt_data with cases w/o subprograms", " - media: i2c: imx214: Use subdev active state", " - media: i2c: imx214: Simplify with dev_err_probe()", " - media: i2c: imx214: Convert to CCI register access helpers", " - media: i2c: imx214: Replace register addresses with macros", " - media: i2c: imx214: Check number of lanes from device tree", " - media: i2c: imx214: Fix link frequency validation", " - scsi: ufs: exynos: Move UFS shareability value to drvdata", " - cgroup/cpuset: Expose cpuset filesystem with cpuset v1 only", " - cgroup/cpuset-v1: Add missing support for cpuset_v2_mode", " - vhost-scsi: Add better resource allocation failure handling", " - vhost-scsi: Fix vhost_scsi_send_bad_target()", " - vhost-scsi: Fix vhost_scsi_send_status()", " - scsi: ufs: mcq: Use ufshcd_mcq_req_to_hwq() to simplify updating hwq", " - riscv: Replace function-like macro by static inline function", " - bpf: Add namespace to BPF internal symbols", " - netfilter: fib: avoid lookup if socket is available", " - drm: panel: jd9365da: fix reset signal polarity in unprepare", " - drm/amd/display: Force full update in gpu reset", " - KVM: x86: Take irqfds.lock when adding/deleting IRQ bypass producer", " - firmware: stratix10-svc: Add of_platform_default_populate()", " - i3c: master: svc: Add support for Nuvoton npcm845 i3c", " - 9p/trans_fd: mark concurrent read and writes to p9_conn->err", " - x86/xen: disable CPU idle and frequency drivers for PVH dom0", " - nvmet-fc: put ref when assoc->del_work is already scheduled", " - scsi: ufs: exynos: Move phy calls to .exit() callback", " - ASoC: fsl_asrc_dma: get codec or cpu dai from backend", " - xfs: do not check NEEDSREPAIR if ro,norecovery mount.", " - xfs: Do not allow norecovery mount with quotacheck", " - xfs: rename xfs_iomap_swapfile_activate to xfs_vm_swap_activate", " - xfs: flush inodegc before swapon", " - selftests/bpf: fix bpf_map_redirect call for cpu map test", " - selftests/bpf: make xdp_cpumap_attach keep redirect prog attached", " - selftests/bpf: check program redirect in xdp_cpumap_attach", " - selftests/bpf: Adjust data size to have ETH_HLEN", " - Revert \"net: dsa: mv88e6xxx: fix internal PHYs for 6320 family\"", " - iommu: Handle race with default domain setup", " - media: i2c: imx214: Fix uninitialized variable in imx214_set_ctrl()", " - usb: typec: class: Unlocked on error in typec_register_partner()", " - Upstream stable to v6.6.89, v6.12.25, v6.12.26", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37986", " - usb: typec: class: Invalidate USB device pointers on partner", " unregistration", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37809", " - usb: typec: class: Fix NULL pointer access", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37816", " - mei: vsc: Fix fortify-panic caused by invalid counted_by() use", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37822", " - riscv: uprobes: Add missing fence.i after building the XOL buffer", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37987", " - pds_core: Prevent possible adminq overflow/stuck condition", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37826", " - scsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37827", " - btrfs: zoned: return EIO on RAID1 block group write pointer mismatch", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37977", " - scsi: ufs: exynos: Disable iocc if dma-coherent property isn't set", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37944", " - wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37761", " - drm/xe: Fix an out-of-bounds shift when invalidating TLB", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37763", " - drm/imagination: take paired job reference", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37764", " - drm/imagination: fix firmware memory leaks", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37869", " - drm/xe: Use local fence in error path of xe_migrate_clear", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37978", " - block: integrity: Do not call set_page_dirty_lock()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37975", " - riscv: module: Fix out-of-bounds relocation access", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37872", " - net: txgbe: fix memory leak in txgbe_probe() error path", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37873", " - eth: bnxt: fix missing ring index trim on error path", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-22120", " - ext4: goto right label 'out_mmap_sem' in ext4_setattr()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37799", " - vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37800", " - driver core: fix potential NULL pointer dereference in dev_uevent()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37878", " - perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37803", " - udmabuf: fix a buf size overflow issue during udmabuf creation", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37879", " - 9p/net: fix improper handling of bogus negative read/write replies", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37983", " - qibfs: fix _another_ leak", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37881", " - usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37805", " - sound/virtio: Fix cancel_sync warnings on uninitialized work_structs", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37883", " - s390/sclp: Add check for get_zeroed_page()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37884", " - bpf: Fix deadlock between rcu_tasks_trace and event_mutex.", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37808", " - crypto: null - Use spin lock instead of mutex", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37985", " - USB: wdm: close race between wdm_open and wdm_wwan_port_stop", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37810", " - usb: dwc3: gadget: check that event count does not exceed event buffer", " length", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37811", " - usb: chipidea: ci_hdrc_imx: fix usbmisc handling", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37812", " - usb: cdns3: Fix deadlock when using NCM gadget", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37813", " - usb: xhci: Fix invalid pointer dereference in Etron workaround", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37815", " - misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler", " registration", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37885", " - KVM: x86: Reset IRTE to host control if *new* route isn't postable", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37817", " - mcb: fix a double free bug in chameleon_parse_gdd()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37819", " - irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37820", " - xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37886", " - pds_core: make wait_context part of q_info", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37887", " - pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37823", " - net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37988", " - fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37824", " - tipc: fix NULL pointer dereference in tipc_mon_reinit_self()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37989", " - net: phy: leds: fix memory leak", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37828", " - scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37829", " - cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37830", " - cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37831", " - cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-37938", " - tracing: Verify event formats that have \"%*p..\"", "", " * Noble update: upstream stable patchset 2025-10-21 (LP: #2129307) //", " CVE-2025-39989", " - x86/mce: use is_copy_from_user() to determine copy-from-user context", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-22026", " - nfsd: don't ignore the return code of svc_proc_register()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37836", " - PCI: Fix reference leak in pci_register_host_bridge()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37846", " - arm64: mops: Do not dereference src reg for a set operation", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37942", " - HID: pidff: Make sure to fetch pool before checking SIMULTANEOUS_MAX", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37856", " - btrfs: harden block_group::bg_list against list_del() races", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37861", " - scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37744", " - wifi: ath12k: fix memory leak in ath12k_pci_remove()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37745", " - PM: hibernate: Avoid deadlock in hibernate_compressor_param_set()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37945", " - net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-", " controlled PHY", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37759", " - ublk: fix handling recovery & reissue in ublk_abort_queue()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23140", " - misc: pci_endpoint_test: Avoid issue of interrupts remaining after", " request_irq error", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-22126", " - md: fix mddev uaf while iterating all_mddevs list", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37765", " - drm/nouveau: prime: fix ttm_bo_delayed_delete oops", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37766", " - drm/amd/pm/powerplay/hwmgr/vega20_thermal: Prevent division by zero", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37767", " - drm/amd/pm/swsmu/smu13/smu_v13_0: Prevent division by zero", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37768", " - drm/amd/pm/powerplay/hwmgr/smu7_thermal: Prevent division by zero", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37769", " - drm/amd/pm/smu11: Prevent division by zero", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37770", " - drm/amd/pm/powerplay: Prevent division by zero", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37768 // CVE-2025-37771", " - drm/amd/pm: Prevent division by zero", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37772", " - RDMA/cma: Fix workqueue crash in cma_netevent_work_handler", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37773", " - virtiofs: add filesystem context source name check", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37775", " - ksmbd: fix the warning from __kernel_write_iter", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37778", " - ksmbd: Fix dangling pointer in krb_authenticate", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37863", " - ovl: don't allow datadir only", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37780", " - isofs: Prevent the use of too small fid", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37781", " - i2c: cros-ec-tunnel: defer probe if parent EC is not present", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37979", " - ASoC: qcom: Fix sc7280 lpass potential buffer overflow", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37784", " - net: ti: icss-iep: Fix possible NULL pointer dereference for perout", " request", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37786", " - net: dsa: free routing table on probe failure", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37864", " - net: dsa: clean up FDB, MDB, VLAN entries on unbind", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37865", " - net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is", " unsupported", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37787", " - net: dsa: mv88e6xxx: avoid unregistering devlink regions which were", " never registered", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37788", " - cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37874", " - net: ngbe: fix memory leak in ngbe_probe() error path", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37789", " - net: openvswitch: fix nested key length validation in the set() action", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37980", " - block: fix resource leak in blk_register_queue() error path", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37790", " - net: mctp: Set SOCK_RCU_FREE", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37875", " - igc: fix PTM cycle trigger logic", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37792", " - Bluetooth: btrtl: Prevent potential NULL dereference", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37867", " - RDMA/core: Silence oversized kvmalloc() warning", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37793", " - ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37982", " - wifi: wl1251: fix memory leak in wl1251_tx_work", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37794", " - wifi: mac80211: Purge vif txq in ieee80211_do_stop()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37796", " - wifi: at76c50x: fix use after free access in at76_disconnect", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23141", " - KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory", " accesses", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37940", " - ftrace: Add cond_resched() to ftrace_graph_set_hash()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37844", " - cifs: avoid NULL pointer dereference in dbg call", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23142", " - sctp: detect and prevent references to a freed transport in sendmsg", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23144", " - backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37892", " - mtd: inftlcore: Add error check for inftl_read_oob()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23145", " - mptcp: fix NULL pointer in can_accept_new_subflow", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23146", " - mfd: ene-kb3930: Fix a potential NULL pointer dereference", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37839", " - jbd2: remove wrong sb->s_sequence check", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23147", " - i3c: Add NULL pointer check in i3c_master_queue_ibi()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23148", " - soc: samsung: exynos-chipid: Add NULL pointer check in", " exynos_chipid_probe()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23149", " - tpm: do not start chip while suspended", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23150", " - ext4: fix off-by-one error in do_split", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23151", " - bus: mhi: host: Fix race between unprepare and queue_buf", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23156", " - media: venus: hfi_parser: refactor hfi packet parsing logic", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23157", " - media: venus: hfi_parser: add check to avoid out of bound access", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37840", " - mtd: rawnand: brcmnand: fix PM resume warning", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37849", " - KVM: arm64: Tear down vGIC on failed vCPU creation", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23158", " - media: venus: hfi: add check to handle incorrect queue size", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23159", " - media: venus: hfi: add a check to handle OOB in sfr region", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23160", " - media: mediatek: vcodec: Fix a resource leak related to the scp device", " in FW initialization", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37850", " - pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37851", " - fbdev: omapfb: Add 'plane' value check", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23161", " - PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37852", " - drm/amdgpu: handle amdgpu_cgs_create_device() errors in", " amd_powerplay_create()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37853", " - drm/amdkfd: debugfs hang_hws skip GPU with MES", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37854", " - drm/amdkfd: Fix mode1 reset crash issue", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-23163", " - net: vlan: don't propagate flags on open", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37857", " - scsi: st: Fix array overflow in st_setup()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37738", " - ext4: ignore xattrs past end", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37739", " - f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37943", " - wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37740", " - jfs: add sanity check for agwidth in dbMount", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37741", " - jfs: Prevent copying of nlink with value 0 from disk inode", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37858", " - fs/jfs: Prevent integer overflow in AG size calculation", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37742", " - jfs: Fix uninit-value access of imap allocated in the diMount() function", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37859", " - page_pool: avoid infinite loop to schedule delayed worker", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37862", " - HID: pidff: Fix null pointer dereference in pidff_find_fields", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37841", " - pm: cpupower: bench: Prevent NULL dereference on malloc failure", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37748", " - iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37749", " - net: ppp: Add bound checking for skb data on ppp_sync_txmung", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37754", " - drm/i915/huc: Fix fence not released on early probe errors", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37755", " - net: libwx: handle page_pool_dev_alloc_pages error", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37757", " - tipc: fix memory leak in tipc_link_xmit", "", " * Noble update: upstream stable patchset 2025-10-17 (LP: #2128722) //", " CVE-2025-37758", " - ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe()", "", " * CVE-2025-37801", " - spi: spi-imx: Add check for spi_imx_setupxfer()", "", " * CVE-2025-39946", " - tls: make sure to abort the stream if headers are bogus", "", " * CVE-2025-38584", " - padata: Fix pd UAF once and for all", " - padata: Remove comment for reorder_work", "", " * CVE-2025-40019", " - crypto: essiv - Check ssize for decryption and in-place encryption", "", " * CVE-2025-38561", " - ksmbd: fix Preauh_HashValue race condition", "", " * CVE-2025-39698", " - io_uring/futex: ensure io_futex_wait() cleans up properly on failure", "" ], "package": "linux", "version": "6.8.0-98.98", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2137901, 1786013, 2136820, 2137528, 2130244, 2128722, 2131265, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2137586, 2135716, 2135261, 1928890, 2112357, 2096976, 2012859, 2031531, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136740, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136361, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2136221, 2134382, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2135261, 2132317, 2065369, 2071861, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134640, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134499, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2134382, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133786, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2133301, 2131046, 2083800, 2127971, 2102077, 2121997, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130344, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2130277, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129559, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2129307, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722, 2128722 ], "author": "Stefan Bader ", "date": "Fri, 09 Jan 2026 13:27:16 +0100" } ], "notes": "linux-modules-6.8.0-100-generic version '6.8.0-100.100' (source package linux version '6.8.0-100.100') was added. linux-modules-6.8.0-100-generic version '6.8.0-100.100' has the same source package name, linux, as removed package linux-modules-6.8.0-90-generic. As such we can use the source package version of the removed package, '6.8.0-90.91', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-image-6.8.0-90-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-90.91", "version": "6.8.0-90.91" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-6.8.0-90-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-90.91", "version": "6.8.0-90.91" }, "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 20260128 to 20260218", "from_series": "noble", "to_series": "noble", "from_serial": "20260128", "to_serial": "20260218", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }